[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