In MSDN there is a widely cited article about lockless programming on x86 and Xbox: http://msdn.microsoft.com/en-us/library/ee418650(v=vs.85).aspx
In short: using boolean as a flag for thread termination is OK. Using boolean as a guard for multi-threaded access to data isn't OK, as read / write reordering can be made both by C++ compiler and CPU. On Thu, Dec 16, 2010 at 00:34, Alexey Proskuryakov <[email protected]> wrote: > > 15.12.2010, в 10:36, Stephan Aßmus написал(а): > >> The only thing one needs to watch out for is to declare such a boolean >> volatile (which I believe this code does, if memory serves). Otherwise the >> thread which polls the condition may read from a cached location and miss >> the change. Worst that can happen on a hypothecial architecture where >> writing a byte is not atomic is that the changed condition takes affect one >> loop cycle later. > > > The behavior of volatile depends on the compiler - there is no guarantee that > a memory barrier will be emitted. Historically, volatile existed not for > multiprocessor systems, but for special addresses in address space (like > memory mapped I/O), where it is important to actually access the address each > time, and not than keep a local variable in a boolean. > > There is code in WebKit that doesn't care about the other thread immediately > seeing the change of a boolean value, and just hopes that it will propagate > soon enough in practice. I remember implementing worker thread termination in > that way. This code is of course formally wrong. > > - WBR, Alexey Proskuryakov > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
