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

[Maciej Stachowiak]

On Dec 15, 2010, at 8:47 AM, Brady Eidson wrote:

> 
> On Dec 15, 2010, at 4:28 AM, Steve Block wrote:
> 
>> I have a question about whether WebCore code makes assumptions about
>> the atomicity of certain read/write operations.
>> 
>> The particular instance I'm interested in is IconDatabase, where
>> m_threadTerminationRequested is written to from the main thread (in
>> close() for example) and read from the DB thread (in
>> syncThreadMainLoop()) without any locking.  It looks like the code is
>> written such that there's no particular synchronization requirement in
>> terms of the order in which the value is set and read. But there's a
>> risk of a garbled read in the case of a simultaneous read and write
>> from the two threads.
>> 
>> I assume that the lack of locking is an intentional decision, based on
>> the fact that on all relevant architectures, a boolean read/write is
>> atomic?
> 
> Correct - or, at least, at the time it was correct.  Have you discovered a relevant architecture where it is no longer correct?
> 
>> Is this a general WebCore policy? It would be great if somebody could
>> confirm this, or point out why I'm wrong.
> 
> I wouldn't be surprised if there were other examples of an unprotected thread shared boolean in either WebCore or any platform's WebKit.
> 
> I *would* be surprised if there was an example of *any other data type* that was shared between threads unprotected.
> 
> That said, I don't think we have any general WebCore policies about multithread practices.  There might be value in such a document.

One possibility is to check the perf impact os using atomic read/write primitives; if it doesn't have a performance cost, it might be safer to do it that way.

 - Maciej