ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/library/sync-barrier-test.cpp

138 lines
4.5 KiB
C++
Raw Permalink Normal View History

Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
/*
SyncBarrier(Test) - verify yield-waiting synchronisation latch
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2023, Hermann Vosseler <Ichthyostega@web.de>
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
/** @file sync-barrier-test.cpp
** unit test \ref SyncBarrier_test
*/
#include "lib/test/run.hpp"
#include "lib/sync-barrier.hpp"
#include "lib/iter-explorer.hpp"
Library/Application: switch Microbenchmark + SyncBarrier tests ...these were already written envisionaging he new API, so it's more or less a drop-in replacement. - cant use vector anymore, since thread objects are move-only - use ScopedCollection instead, which also has the benefit of allocating the requires space up-front. Allow to deduce the type parameter of the placed elements
2023-10-03 22:56:09 +02:00
#include "lib/thread.hpp"
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
#include <chrono>
#include <atomic>
#include <array>
using test::Test;
using lib::explore;
using std::array;
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
using std::atomic_uint;
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
using std::this_thread::sleep_for;
using namespace std::chrono_literals;
namespace lib {
namespace test {
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
namespace {// Test setup for a concurrent calculation with checksum....
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
Library: fix cause of the deadlock in Session-Thread ... which became apparent after switching to the new Thread-wrapper implementation ... the reason is a bug in the Thread-Monitor (which will also be reworked soon)
2023-10-01 20:29:11 +02:00
const uint NUM_THREADS = 256;
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
atomic_uint stage1{0};
atomic_uint stage2{0};
atomic_uint finish{0};
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
SyncBarrier interThread{NUM_THREADS };
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
SyncBarrier afterThread{NUM_THREADS+1};
/**
* A test thread to perform a summation protocol including synchronisation points
* - build a compound sum of random numbers in the first stage
* - wait for the compound sum to build up completely
* - book in the compound sum plus a further random number
*/
class TestThread
Library/Application: switch Microbenchmark + SyncBarrier tests ...these were already written envisionaging he new API, so it's more or less a drop-in replacement. - cant use vector anymore, since thread objects are move-only - use ScopedCollection instead, which also has the benefit of allocating the requires space up-front. Allow to deduce the type parameter of the placed elements
2023-10-03 22:56:09 +02:00
: public lib::Thread
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
{
public:
TestThread()
Library/Application: switch Microbenchmark + SyncBarrier tests ...these were already written envisionaging he new API, so it's more or less a drop-in replacement. - cant use vector anymore, since thread objects are move-only - use ScopedCollection instead, which also has the benefit of allocating the requires space up-front. Allow to deduce the type parameter of the placed elements
2023-10-03 22:56:09 +02:00
: Thread{"Load Test"
Library: now using controlled seed and replaced `rand` (closes #1378) After augmenting our `lib/random.hpp` abstraction framework to add the necessary flexibility, a common seeding scheme was ''built into the Test-Runner.'' * all tests relying on some kind of randomness should invoke `seedRand()` * this draws a seed from the `entropyGen` — which is also documented in the log * individual tests can now be launched with `--seed` to force a dedicated seed * moreover, tests should build a coherent structure of linked generators, especially when running concurrently. The existing tests were adapted accordingly All usages of `rand()` in the code base were investigated and replaced by suitable calls to our abstraction framework; the code base is thus isolated from the actual implementation, simplifying further adaptation.
2024-11-17 19:45:41 +01:00
,[&, ran=lib::Random{seedFromDefaultGen()}]
() mutable
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
{ //-STAGE-1------------------------------
Library: now using controlled seed and replaced `rand` (closes #1378) After augmenting our `lib/random.hpp` abstraction framework to add the necessary flexibility, a common seeding scheme was ''built into the Test-Runner.'' * all tests relying on some kind of randomness should invoke `seedRand()` * this draws a seed from the `entropyGen` — which is also documented in the log * individual tests can now be launched with `--seed` to force a dedicated seed * moreover, tests should build a coherent structure of linked generators, especially when running concurrently. The existing tests were adapted accordingly All usages of `rand()` in the code base were investigated and replaced by suitable calls to our abstraction framework; the code base is thus isolated from the actual implementation, simplifying further adaptation.
2024-11-17 19:45:41 +01:00
localSum = ran.i(1000); // generate local value
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
stage1.fetch_add (localSum); // book in local value
interThread.sync(); // wait for all other threads to have booked in
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
//-STAGE-2------------------------------
uint sync = stage1; // pick up compounded sum from STAGE-1
Library: now using controlled seed and replaced `rand` (closes #1378) After augmenting our `lib/random.hpp` abstraction framework to add the necessary flexibility, a common seeding scheme was ''built into the Test-Runner.'' * all tests relying on some kind of randomness should invoke `seedRand()` * this draws a seed from the `entropyGen` — which is also documented in the log * individual tests can now be launched with `--seed` to force a dedicated seed * moreover, tests should build a coherent structure of linked generators, especially when running concurrently. The existing tests were adapted accordingly All usages of `rand()` in the code base were investigated and replaced by suitable calls to our abstraction framework; the code base is thus isolated from the actual implementation, simplifying further adaptation.
2024-11-17 19:45:41 +01:00
localSum += ran.i(1000); // add further local value for STAGE-2
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
stage2.fetch_add (localSum+sync); // book in both local values and synced sum
afterThread.sync(); // wait for other threads and supervisor
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
finish.fetch_add(1); // mark completion of this thread
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
}}
{ }
uint localSum; // *deliberately* not initialised to avoid race
};
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
/** sum up all `localSum` fields from all TestThread instances in a container */
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
template<class CON>
uint
sumLocals (CON const& threads)
{
Library: generalise pipeline summation into fold-left Using the same building blocks, this operation can be generalised even more, leading to a much cleaner implementation (also with better type deduction). The feature actually used here, namely summing up all values, can then be provided as a convenience shortcut, filling in std::plus as a default reduction operator.
2023-09-24 02:45:43 +02:00
return explore (threads)
.reduce ([&](TestThread const& t){ return t.localSum; });
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
}
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
}//(End)Test setup
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
/*******************************************************************//**
* @test verify N-fold synchronisation points by multi-thread loat-test.
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
* - start a _huge number_ of TestThread
* - all those pick up the partial sum from stage1
* @remark without coordinated synchronisation, some threads would see
* an incomplete sum and thus the stage2 checksum would be lower
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
* @see lib::SyncBarrier
* @see steam::control::DispatcherLoop
*/
class SyncBarrier_test : public Test
{
virtual void
run (Arg)
{
Library: now using controlled seed and replaced `rand` (closes #1378) After augmenting our `lib/random.hpp` abstraction framework to add the necessary flexibility, a common seeding scheme was ''built into the Test-Runner.'' * all tests relying on some kind of randomness should invoke `seedRand()` * this draws a seed from the `entropyGen` — which is also documented in the log * individual tests can now be launched with `--seed` to force a dedicated seed * moreover, tests should build a coherent structure of linked generators, especially when running concurrently. The existing tests were adapted accordingly All usages of `rand()` in the code base were investigated and replaced by suitable calls to our abstraction framework; the code base is thus isolated from the actual implementation, simplifying further adaptation.
2024-11-17 19:45:41 +01:00
seedRand();
// Launch several TestThread
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
array<TestThread,NUM_THREADS> threads;
CHECK (0 == finish);
Library/Application: switch Microbenchmark + SyncBarrier tests ...these were already written envisionaging he new API, so it's more or less a drop-in replacement. - cant use vector anymore, since thread objects are move-only - use ScopedCollection instead, which also has the benefit of allocating the requires space up-front. Allow to deduce the type parameter of the placed elements
2023-10-03 22:56:09 +02:00
CHECK (explore(threads).and_all());
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
afterThread.sync();
Library: implement and verify SyncBarrier
2023-09-23 18:05:17 +02:00
sleep_for (5ms); // give the threads a chance to terminate
Library: draft a SyncBarrier latch Intended as replacement for the Mutex/ConditionVar based barrier built into the exiting Lumiera thread handling framework and used to ensure safe hand-over of a bound functor into the starting new thread. The standard requires a comparable guarantee for the C++17 concurrency framework, expressed as a "synchronizes_with" assertion along the lines of the Atomics framework. While in most cases dedicated synchronisation is thus not required anymore when swtiching to C++17, some special extended use cases remain to be addressed, where the complete initialisation of further support framework must be ensured. With C++20 this would be easy to achieve with a std::latch, so we need a simple workaround for the time being. After consideration of the typical use case, I am aiming at a middle ground in terms of performance, by using a yield-wait until satisfying the latch condition.
2023-09-22 21:55:53 +02:00
CHECK (NUM_THREADS == finish); // all threads have passed out....
CHECK (0 < stage1);
CHECK (stage1 < stage2);
CHECK (stage2 > sumLocals(threads));
CHECK (stage2 == sumLocals(threads) + NUM_THREADS*stage1); // this holds only if all threads waited to get the complete stage1 sum
}
};
/** Register this test class... */
LAUNCHER (SyncBarrier_test, "function common");
}} // namespace lib::test
Reference in a new issue Copy permalink