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