[fpc-pascal] Where is IsMultiThreaded set under Linux?

Andrew Brunner andrew.t.brunner at gmail.com
Fri Oct 8 18:12:44 CEST 2010


On Fri, Oct 8, 2010 at 9:52 AM, Jonas Maebe <jonas.maebe at 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 :-(



More information about the fpc-pascal mailing list