On 08 Oct 2010, at 16:33, Andrew Brunner wrote:
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.
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.
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.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
