Let the tasking layer say how much parallelism is available.

We're moving toward having the tasking layer tell the rest of Chapel
(notably the module code) how much parallelism it thinks it can provide,
instead of the module code (et al.) deciding that on its own based on
how much hardware it sees.  This is the first step along that path.  It
augments the processor-counting support in the runtime so that we can
get an accurate count of the number of cores and processor units (PUs,
basically anything that can issue instructions, including hyperthreads).
And, it adds a chpl_getMaxPar() call to the tasking layer interface, to
say how much true parallelism the tasking layer implementation thinks it
can provide.  Only the fifo and massivethreads layers are done so far,
and the module code hasn't been updated to use this information.  It's
still looking directly at how much hardware is configured.

The specific file changes are as follows.

runtime/include/chplsys.h
runtime/src/chplsys.c
  Rename chpl_numCoresOnThisLocale() as chpl_getNumPUsOnThisNode()
  (since #PUs is what it actually returned) and re-implement it for
  Linux to reflect kernel scheduling affinity, not just what hardware is
  present.  Add a new chpl_getNumCoresOnThisNode(), which returns the
  number of cores available to the process.  This new function is a copy
  of ...getNumPUs..., adjusted to return the number of actual cores (no
  hyperthreads or equivalent).  Make both of these return a regular int;
  chpl_numCoresOnThisLocale() returned an int64_t, but I can't think of
  a good reason to retain that.

runtime/include/chpl-tasks.h
runtime/src/tasks/fifo/tasks-fifo.c
runtime/src/tasks/massivethreads/tasks-massivethreads.c
  Add the new tasking interface function chpl_task_getMaxPar().
  Implement it in terms of chpl_getNumCoresOnThisNode() (added above).
  Also, in fifo tasking, call chpl_getNumPUsOnThisNode() instead of
  chpl_numCoresOnThisLocale() (which actually returned #PUs) when
  deciding whether to spin or use a pthread cond var while waiting for a
  sync var to be in the desired state.  And, while here, clarify the
  associated comment.

modules/internal/ChapelLocale.chpl
modules/internal/localeModels/flat/LocaleModel.chpl
  Add a new maxTaskPar member to the LocaleModel module, and initialize
  it by calling chpl_task_getMaxPar().

test/localeModels/gbt/maxTaskPar.chpl
test/localeModels/gbt/maxTaskPar.cleanfiles
test/localeModels/gbt/maxTaskPar.prediff
  Add a new test to ensure that here.maxTaskPar has the expected value.
Clean up in a few spots.

In chplsys, for Linux and Cygwin define chpl_getNumCoresOnThisNode() in
terms of the number of PUs returned by chpl_getNumPUsOnThisNode().

In flat/LocaleModel.chpl initialize numCores with the value returned by
chpl_getNumPUsOnThisNode(), which returns what used to be returned by
chpl_numCoresOnThisLocale().  Thus the value of numCores will be the
same as it was before all this work.
Add maxTaskPar support in qthreads tasking and numa locale model.

This adds chpl_task_getMaxPar() in qthreads tasking, and updates the
numa locale model to include a maxTaskPar member and initialization of
that.

While here, I also corrected the return types of the runtime functions
that return #PUs and maxTaskPar, in the extern decls in the flat locale
model.
Fix a function call I missed.

I neglected to change a call to chpl_numCoresOnThisLocale() into a call
to chpl_getNumPUsOnThisNode().  (It's a call that really is looking for
the number of PUs on the node.)
Sorting the file systems now
Merge branch 'master' of github.com:chapel-lang/chapel into taskrt-concurrency
changing the hdfs files to be C files
HDFS now uses CHPL_AUXIO_INCLUDE and CHPL_AUXIO_LIBS
Merge pull request #155 from tzakian/hdfs_env_variable_changes

Changing HDFS to use CHPL_AUXIO_INCLUDE and CHPL_AUXIO_LIBS for library and include paths. Updating README.hdfs to reflect this as well.
Merge pull request #154 from tzakian/hdfs_makefile_changes

Change HDFS files to C, and use a C compiler to compile them.
Merge pull request #153 from tzakian/auxio_env_sort

We currently use printchplenv --make to determine the path for the gen directory. Since we were not sorting the names in the environment variable for CHPL_AUX_FILESYS we wound up viewing CHPL_AUX_FILESYS="hdfs curl" as different from CHPL_AUX_FILESYS="curl hdfs".

This fixes this problem by first sorting the string before adding the underscores for the path.

Reviewed by @kyleb
Finalize support for numa and add darwin.

This fixes problems in maxTaskPar support with CHPL_LOCALE_MODEL=numa,
and adds support for the darwin (Mac) platform.  I've tested on linux
with tasks=(fifo,massivethreads,qthreads) and locale model=(flat,numa)
in all combinations, and on darwin with tasks=fifo and both locale
models.  Note: I've tested only the one new test, not anything else
(well, maybe a hello here and there).  That should be sufficient, since
I'm not yet changing behavior, just adding the new locale model member.

The specific file changes are as follows.

runtime/src/chplsys.c
  Take the #warnings out of the '#ifdef __APPLE__' code, so that it can
  build.  While here, also remove the #warnings for #ifdef __CYGWIN__,
  though I haven't been able to test that yet.

modules/internal/localeModels/numa/LocaleModel.chpl
  If there are no sublocales (as with CHPL_TASKS=fifo), set maxTaskPar
  to chpl_task_getMaxPar(), on the assumption that the tasking layer
  will behave like CHPL_LOCALE_MODEL=flat in this case.

test/localeModels/gbt/maxTaskPar.chpl
  Make this new test recursively print maxTaskPar for any sublocales.

test/localeModels/gbt/maxTaskPar.prediff
  Add a bunch of elaboration to compute what we think the program ought
  to print, and make a .good file containing that.
Initial commit to try and get rid of qthread deadlock

There are a couple of tests that deadlock with qthreads now that the nemesis
scheduler is the default. They are tests where the main task is in a loop
waiting for a sync var to have a certain value and other tasks are being
created inside the while loop to increment the sync var. Some of the tasks
getting created never get to run because the main task never yields and thus
the main loop is waiting for tasks that it's not letting run to update a value.
To remedy this the plan is to do a qthread_yield every x unlocks for any given
sync var. This does a qthread_yield every 1024 iterations. I tried with 32 and
256 and they both seemed to yield too often through the non-scientific method
of putting some prints when we yield and seeing how often we yield for a few
test programs and also checking how long they take to finish into account.
Improved constness checking on fields; adjusted Chapel code.
Fix updateBuildVersion bug so we don't always rebuild version.cpp

The updateBuildVersion script had a bug that caused it to always think there
was a new version. It was testing ("versionNum" eq versionNum), including
quotes as characters for one of the strings, so they are always different.
This just removes the quotes.
Update to how often qthreads yields for sync var unlock

This moves the check to use the return value of qthreads_incr, which means we
get the previous value of lockers_out but we get rid of a race.

The previous code was something like if (lockers_out & 0xFF) then yield but you
want if ((lockers_out &0xFF) == 0) since the other way yields for all but the
one iteration. Finally, this bumps up the number of unlocks before yielding.
This is based on trials with test/domains/sungeun/assoc/stress.numthr.chpl .
No stack checks, and smaller stack for domains/sungeun/assoc/stress.numthr.chpl

For qthreads this test was running out of memory because there were too many
tasks existing at the same time. This was especially a problem with 8M stacks
so this lowers that to 128 and turns of guard pages to reduce memory usage and
because this test creates a lot of tasks. I believe this wasn't an issue for
fifo because there is a limited number of pthreads (and thus stacks) that can
exist, whereas qthreads imposes no such limit.
Don't yield for first unlock of sync var for qthreads sync var unlock

Previously yield for if ((lockers_out % 4096) == 0) meant we would yield on the
first unlock. This just changes it to if ((lockers_out % 4096) == 4095) so that
we still yield after the same number of iterations but the first yield is moved
back to the 4095 unlock instead of the first.
Lower how many iterations until we yield
Merge pull request #159 from ronawho/qthreads-syncvar-deadlock

Do a qthread_yield() after X number of unlocks on a sync variable

Note: This idea was ok'd and comes from greg and sung. This exact patch hasn't
been reviewed, but it passed full testing and I want to see the performance
results so that we can setup something for good testing over the weekend and
hopefully switch to qthreads as default after the weekend. After seeing the
performance and correctness results I'll update the patch and have it formally
reviewed.

After switching to the nemesis scheduler as the default scheduler for qthreads
we had 5 deadlocks essentially coming from 2 tests:
test/domains/sungeun/assoc/stress.chpl and test/users/shetag/fock/fock-1.chpl.

In these tests the main task is waiting for a sync var to have a certain value
while other tasks are incrementing that sync var. In this case some tasks that
are adding to the sync var are put on to run on the same worker as the main
task. The main task is never yielding and thus it keeps waiting for a sync var
to have a value that it is preventing from getting updated.

To remedy this, we now yield after 256 unlocks of any given sync var. The
specific number has come from some trial and error with the previous tests and
will probably change after some more trial and error and looking through
performance results.

This also lowers the stack size for a test that creates an enormous amount of
threads and turns off guard pages to avoid running out of memory.