On Fri, Oct 8, 2010 at 9:21 AM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > No, the main source of problems is that the cpu may reordering memory > operations resulting in those booleans in the arrays becoming true before > all memory locations written in the thread are visible. The result is that > you may try to use data that the thread should have written earlier, but > that in fact is not yet available even though the boolean is already true. > > In fact, using atomic operations won't help to solve that problem, you do > need memory barriers to flush the memory writes (most pthread functions and > ending a pthread guarantee memory barrier behaviour, which is why WaitFor() > itself is safe). > > On x86 you're unlikely to encounter many problems because of the strongly > consistent memory model, but at least x86-64 now also has read and write > barrier instructions. On non-x86 architectures, you definitely need memory > barriers in such cases. >
So are you referring to the topic of this conversation regarding data flushing? The notion of creating an index of completions to poll and waiting for all the values to turn true as a means to determine actual job completion without using locking mechanisms is just one viable solution. Are you implying that the log data (which is the purpose for this/these worker threads) needs to be flushed prior to tripping the boolean or are you saying that the boolean array needs to be flushed? As a solution I just don't see any problems with boolean values coming back as being true *before* they were assigned as complete. Pre-emptive completion - I just don't see that. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
