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

Brady Eidson beidson at apple.com
Wed Dec 15 08:47:20 PST 2010


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.

~Brady

> 
> Thanks,
> Steve
> 
> -- 
> Google UK Limited
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
> Registered in England Number: 3977902



More information about the webkit-dev mailing list