Leon Mergen wrote:
Hello,
I'm currently trying to achieve the following:
A series of threads handle jobs (threads A). Of each of these jobs, in the end, a statistics object is placed in a container. This container will later be read-from by another thread (thread B), dedicated to continuously reading statistics data from other threads, and parse those statistics.
Now, since it is very well possible a thread handles at least 1,000 jobs before statistics data is actually read from, I want it to hold a mutex lock to the data at all time.
How long do these jobs take? Unless they take less than 100,000 cycles (that's about 50 microseconds on a current processor) I would be surprised if the use of a mutex when adding a statistics object would slow things down much, given that you seem to be saying the mutex will generally be uncontended.
The class also has an internal volatile boolean, which flags whether another thread (thread B) wants to read from the container. If so, the writing thread (threads A) releases the lock,
When does the writing thread poll this flag?
after which thread B will pick up the lock and write the data and resets the boolean flag. After releasing the lock, threads A will immediately try to re-acquire the lock. <snip>
You might find that this works on your development machine, but it will likely fail elsewhere. There is no guarantee that releasing a mutex that's blocking another thread is will wake that other thread. Ben.