Re: [Boost-users] Locking mechanisms other than scoped_lock

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.