Although a future thread used an atomic compare-and-swap to
set "is a list" or "not a list" flag on pairs via the
JIT-implemented `list?', the hashing function in the runtime
thread did not; as a result, it might be possible to lose
a hash code due to cache inconsistency (although I'm not
sure it's actually possible, and I couldn't trigger a problem
with a test). Most of the changes are related to using
an atomic compare-and-swap when setting a hash code, as
well as clean-ups to related code. Processor-count tests
avoid using atomic compare-and-swap on uniprocessors, which
might not support the relevant machine instructions.
As significantly, the compare-and-swap operation for the
JIT-implemented `list?' did not actually set flags on
a pair that has a hash code. This could lead to `list?'
tests that were not constant time (but only if the relevant
pair's `eq?' hash code had been used previously).
- abstract over JIT inlining of fsemaphore operations
- fix problems with non-parallel fsemaphores
- adjust tests so they don't assume too much concurrency
- clarify fsemaphore vs. semaphore in the docs
if no future thread is running the future; also adjust the
policy for suspending a future so that even synchronized
operations can suspend if there's other work to be done;
also also fix `current-future' for nested `touch'es and when
parallel futures are disabled
which required adding a notion of "lightweight continuation" to
the runtime system, where a lightweight continuation involves
only frames from JIT0generated code (so that details of the stack
layout are known, for example)
