Kesseli Pascal wrote:
Hi everyone
Recently I was trying to synchronize one of my functions using the following code:
// write own data to shared vector... // ... if (++numberOfReadyThreads < numberOfInvolvedThreads) { allChargingDataReady.wait(lock); return; } numberOfReadyThreads = 0; // Only the last thread enters this
// write data to file... allChargingDataReady.singal_all();
The idea is that all threads submit their data using this function and then wait before reading in the next set of data until all threads have submitted their data. The last thread to submit his data is the one who has to write the collected data to a file.
Using this structure, I find it very simple to realize this behavior. However, I know from programming with Java that the VM there sometimes awakens one's threads without any reason, which means that I would have
to
realize my condition like this instead:
// ... while(numberOfReadyThreads < numberOfInvolvedThreads) { allChargingDataReady.wait(lock); } // ...
Implementing the same behavior using this snippet is much more complicated though and I would rather avoid it if possible.
Why is it more complicated?
And that leads us right away to my question:
Is the while()-workaround using Boost & C++ needed as well as in Java? Or can I use the much simpler if()-version?
As docs say, you need to test your condition in a loop in Boost.Threads. This is not a particular property of Java or Boost.Threads -- that's how POSIX threads work. (Windows don't have native condition, and I have much clue how conditions are simulated on windows and whether window Event
Hey Ya
Thanks for the quick reply. Well, it would be more complicated in the way
that the only condition that would keep in the loop would be the number of
threads already arrived on this condition (numberOfThreadsReady). As soon as
all threads have arrived, this number is set back to zero, which would keep
the threads waiting if they re-checked this condition.
But I found out that Boost supports a much more suitable solution for this
problem, namely the barrier class. And, concerning the use of a barrier, I
trust I am not mistaken that there is no loop needed when calling
barrier.wait(), or is there :) ?
If so, that would call my complete understanding of the barrier mechanism
into question :) .
Thanks again & greeetz
Pascal
"Vladimir Prus"
has similar behaviour).
- Volodya
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.16/1251 - Release Date: 30.01.2008 09:29