Re: Boost.Threads - Questions

From: williamkempf_at_[hidden]
Date: 2001-08-20 19:47:30

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> williamkempf_at_h... wrote:
> 
> > How?  Pass "f"
> > a parameter that includes a monitor construction which the thread
> > waits for.
> 
> 	Urgle. Isn't that a bit complex a technique for a simple
> exchange of identities?

Not once wrapped ;).  Seriously, though, this is a fairly standard 
answer to this issue.  Neither POSIX nor Win32 provide a "better" 
solution.

> > While I'm thinking about it, there's an even easier method for 
doing
> > this.  It creates a minor race condition,
> 
> 	What is a "minor race condition"? 
> Do you mean (in the example) that a get() by the child thread may
> return the initial 0 value, before the smart pointer actually
> receives the thread object pointer? That may not be a minor problem,
> such an error may result in caching the value on a multi-processor
> system, so that all subsequent reads up to a synchronisation point
> are wrong. Worse, the user may cache the value, which means
> its permanently wrong. There's no such thing as a minor fault
> in software. Its either correct, or its not. Would you allow
> a 'minor race condition' in your heart pacemaker? :-)

A "minor" race condition is one which exists in theory, but practical 
concerns make it unlikely, or even impossible, to occur in reality.  
For instance, if the spawned thread were to sleep for a period of 
time you can be assured that the race will never occur.  Or, on first 
access within the thread you could even do a busy wait and have no 
problems with a race.  In other words, there's not enough details to 
be able to definatively say that a race condition will occur.

Bill Kempf