The investigation for #1279 leads to the following conclusions - the features and the design of our custom thread-wrapper almost entirely matches the design chosen meanwhile by the C++ committee - the implementation provided by the standard library however uses modern techniques (especially Atomics) and is more precisely worked out than our custom implementation was. - we do not need an *active* threadpool with work-assignment, rather we'll use *active* workers and a *passive* pool, which was easy to implement based on C++17 features ==> decision to drop our POSIX based custom implementation and to retrofit the Thread-wrapper as a drop-in replacement +++ start this refactoring by moving code into the Library +++ create a copy of the Threadwrapper-code to build and test the refactorings while the application itself still uses existing code, until the transition is complete
44 lines
747 B
Text
44 lines
747 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 "Thread-local diagnostic context" DiagnosticContext_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 "Create 20 Threads passing context" ThreadWrapper_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Waiting on Thread termination" ThreadWrapperJoin_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|
|
TEST "Detect code runing in a given Thread" ThreadWrapperSelfRecognitionTest_test <<END
|
|
return: 0
|
|
END
|
|
|
|
|