[webkit-dev] Atomic read/write operations and thread safety
Brady Eidson
beidson at apple.com
Wed Dec 15 09:43:14 PST 2010
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.
In hindsight I realize my response involved assumptions about this code that were known to me but not to the general audience, so I'll followup more thoroughly.
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. My belief is that this is safe for booleans, but I would love to hear where I'm wrong.
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.
If there's a specific race condition in this code you've spotted, I'd love to hear how it would manifest!
Thanks,
~Brady
> 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.
>
> ~Brady
>
>>
>> Thanks,
>> Steve
>>
>> --
>> Google UK Limited
>> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
>> Registered in England Number: 3977902
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
More information about the webkit-dev
mailing list