tests/accumulator/*.m:
tests/analysis_*/*.m:
tests/benchmarks*/*.m:
tests/debugger*/*.{m,exp,inp}:
tests/declarative_debugger*/*.{m,exp,inp}:
tests/dppd*/*.m:
tests/exceptions*/*.m:
tests/general*/*.m:
tests/grade_subdirs*/*.m:
tests/hard_coded*/*.m:
Make these tests use four-space indentation, and ensure that
each module is imported on its own line. (I intend to use the latter
to figure out which subdirectories' tests can be executed in parallel.)
These changes usually move code to different lines. For the debugger tests,
specify the new line numbers in .inp files and expect them in .exp files.
This test case is based off Sebastian Godelet's work, which found a bug that
can occur when release/3 is called on a barrier and then other calls to
wait/3 are made. The final call to wait/3 tries to execute the normal
'unblock the barrier' code and deadlocks there because the barrier is
already unlocked, specifically a value is already present in the "Go" mvar.
Thanks Sebastian for your test case.
library/thread.barrier.m:
Handle release/3 properly: release/3 now sets the number of remaining
threads to reach the barrier to zero, and wait/3 will determine why this
iz zero (it's normally at least one), and if it is because release was
called then no error is raised. The other reasion why the number of
remaining threads may be zero is because wait has been called too many
times, in this case wait/3 will throw an exception.
tests/hard_coded/Mmakefile:
tests/hard_coded/thread_barrier_test.exp:
tests/hard_coded/thread_barrier_test.m:
Add new test case.
tests/hard_coded/thread_test_utils.m
This module contains code that may be useful for other concurrency
tests.
