Boost logo

Boost Users :

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2005-03-21 08:59:07


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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net