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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
