Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: williamkempf_at_[hidden]
Date: 2001-07-05 08:44:35

--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Alexander Terekhov wrote:
> > 
> > > > http://www.acm.org/classics/feb96/
> > > >
> > > > "Monitors: An Operating System Structuring Concept
> > > >  C.A.R Hoare..."
> > >
> > > Thanks. This seems to be another case of me reinventing the 
wheel. :-)
> > > What he's describing there seems to be the concept I put in my 
thread
> > > library under the name Flag.
> > 
> > i do not think so.. condition variables are stateless and
> > they are working together with mutex providing atomic
> > unlock_and_wait semantics (with respect to other threads
> > and CV/mutex).
> 
> I meant that my Flag == his Monitor, not Flag == CV. If you 
disagree,
> please explain what the difference is.
> 
> > note that auto-reset event is simply a binary semaphore.
> > manual-reset events also have state. it is really difficult
> > to use events due to all sorts of race conditions with
> > respect to "program" state and event state.
> 
> I keep seeing assertions to that effect, but I've never seen any 
attempt
> to justify the claim. Could you please supply a logical argument 
instead
> of a bare take-my-word-for-it? (Your example using my RWL doesn't 
count;
> I did say it was newly written and poorly tested, I expected it to 
still
> have some bugs.)

The key is that the external mutex (when talking about CV types, or 
for a monitor it's the hidden mutex) must be unlocked during the 
blocking period of a wait() *only*.  In other words, the mutex is 
locked before and after the wait, but not during.  With an event 
object as defined by Win32 you'd code this as:

ReleaseMutex(mutex);
WaitForSingleObject(event, INFINITE);
WaitForSingleObject(mutex, INFINITE);

The problem should be self evident from this.  After you wait on the 
event there's a possibility for a race in acquiring the mutex.  When 
the "event" is the change of some state by the time we can re-acquire 
the mutex this state may no longer hold true.

If you really want in depth discussions about how the race conditions 
occur with various implementations read the classic article on 
building Win32 CV concepts posted earlier in this thread 
(http://www.cs.wustl.edu/~schmidt/win32-cv-1.html).

(BTW, I posted this info earlier, along with other remarks, but it 
appears to have disappeared into the ether.  Too bad, because I had 
other things to say, but I don't have time to go back and try and 
recreate my response.)

Bill Kempf