...while reworking the application code, it became clear that actually there are two further quite distinct variants of usage. And while these could be implemented with some trickery based on the Thread-wrapper defined thus far, it seems prudent better to establish a safely confined explicit setup for these cases: - a fire-and-forget-thread, which manages its own memory autonomously - a thread with explicit lifecycle, with detectable not-running state
59 lines
1,017 B
Text
59 lines
1,017 B
Text
TESTING "Library Test Suite: concurrency helpers" ./test-suite --group=common
|
|
|
|
|
|
|
|
TEST "Multithread Locking by Monitor" SyncLocking_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Multithread Locking class level" SyncClasslock_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "N-fold synchronisation barrier" SyncBarrier_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Yield-waiting sync performance" SyncBarrierPerformance_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Wait/Notify on Object Monitor" SyncWaiting_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Wait/Notify with timeout" SyncTimedwait_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Run function concurrently" ThreadWrapper_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Waiting on Thread termination" ThreadWrapperJoin_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
PLANNED "Launch self-contained detached Thread" ThreadWrapperAutonomous_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
PLANNED "Detect Thread lifecycle state changes" ThreadWrapperLifecycle_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Detect running in specific Thread" ThreadWrapperSelfRecognitionTest_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|