On 8 October 2010 17:12, Andrew Brunner <andrew.t.brun...@gmail.com> wrote: > On Fri, Oct 8, 2010 at 9:52 AM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: >>> 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 >> >> Yes. >> >>> or are you saying that the boolean array needs to be >>> flushed? >> >> That's not necessary if all the various threads do is setting the values to >> true. If you reset them to false inside newly started/resumed threads >> (although that would be strange), then you may have to flush it. > > Right. So you *were* talking about the actual log data being 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. >> >> If you have in a thread: >> >> buffer:=nil; >> finishedarray[threadnr]:=true; >> >> Then another thread (including the main program) running on a different core >> can see both (finishedarray[threadnr]=true) and (buffer<>nil) at the same >> time, except probably on x86. This can be prevented by adding memory barrier >> between those statements. A memory barrier orders whatever memory operations >> come before it with respect to those that come after it. > >> Depending on the internal state that these logging threads use and whether >> or not its reused or read later on, that may or may not be important. > > That may be true with regard to actual disk writing, but when polling > occurs and the value is read as true, any thread can assume it was > already tripped. And I agree that other attributes' values may or may > not be accurate to observing threads, but I (assume you agree as well) > false positives are impossible for the purpose of polling as stated. > If not, I missed your point :-(
I think Jonas was talking about out of order execution in the cpu, not disk i/o. Henry _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
