[webkit-dev] Atomic read/write operations and thread safety

Steve Block steveblock at google.com
Wed Dec 15 11:11:00 PST 2010

Thanks for the reply Brady.

> The boolean in question isn't both checked and set at the same time - it's not an acquired resource.  One
> thread sets it, the other checks it.
I don't follow. If it's set from one thread and checked from another
thread without locks, how can you guarantee this (other than with
application logic)?

> Additionally, while there isn't a guard specifically around the boolean, there is the "m_syncLock" Mutex
> which is implicitly guarding operations on this bool, so the "thread safety of a bool?" argument becomes
> somewhat moot.
Ah, so you're saying that there's application logic using m_syncLock
to prevent the boolean from being written and read at the same time? I
didn't spot that.

> I have seen this particular technique quite often before. The only thing one
> needs to watch out for is to declare such a boolean volatile (which I
> believe this code does, if memory serves). Otherwise the thread which polls
> the condition may read from a cached location and miss the change.
The boolean in question isn't volatile. This isn't a problem because
as I mentioned, there's no requirement for a given write to be picked
up by a particular read. If a read 'misses' a write, we'll pick it up


More information about the webkit-dev mailing list