David Given <[hidden email]> wrote:
> > I am not sure that this line is indeed a problem. Isn't checking an int
> > an atomic operation? As aTask is declared volatile, it should be
> > re-referenced, so a change during the loop would not be a problem
> > either.
> Ah, but that's not an atomic operation. That line compiles into something like:
You're right, of course. I was fixed on the comparison (which may indeed
be atomic) but the surrounding pointer arithmetic clearly isn't. I'll
have some more fun with fiddling the mutex then.
There aren't really all that many things that are guaranteed atomic.
The simple comparison is, but even an increment isn't guaranteed. If
you have code that does
where foo is shared between threads, you might lose an update. This
despite there being atomic increment machine instructions.
Rule of thumb is all updates are non-atomic, and so are all reads
through a shared pointer, if that pointer moves around.