Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk