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" schrieb im Newsbeitrag news:... section. thing

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