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 later. Steve _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
