Re: [Boost-users] [Boost.Threads] Exiting Thread Properly

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-12-28 08:39:04

Roland Schwarz wrote:
> What makes you believe, you need not protect access to the shared flag?
> It would be ok, if you knew flag is atomic, but in general you will 
> create non portable code this way.
>   
What makes me believe it is that there will ever only be one writer.

You cannot exactly determine when the slave thread stops. It only checks
the flag once per iteration anyway. What's the worst thing that can
happen if the flag is not atomic? The slave thread runs one more
iteration. Makes no difference. The thread might also have just finished
checking the flag before you set it. You'd have to put the entire loop,
i.e. the check for the flag and the subsequent work item, under a mutex
to ensure that the thread doesn't do any work anymore after the flag is
set. Of course that means that the thread stopping function will block
until the mutex becomes free. There is no guarantee that the thread
won't perform any more work from the moment the stopping function is
called. There merely is a guarantee that the thread has stopped
processing by the time the canceller returns, and you can achieve the
same effect cheaper (because the worker thread doesn't operate under a
mutex) by just joining with the worker thread in the canceller.
The only possible issue is CPU-specific caches in a multi-CPU system.
However, I believe the volatile pointer should ensure that the value
propagates to all CPUs. (You might want to make the pointer in the
canceller volatile, too.)

Is there any issue that I'm not aware of? Can the reader thread somehow
"undo" the write because the write isn't atomic?

Sebastian Redl