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

Henry Vermaak henry.vermaak at gmail.com
Fri Oct 8 19:35:12 CEST 2010


On 8 October 2010 17:12, Andrew Brunner <andrew.t.brunner at gmail.com> wrote:
> 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 :-(

I think Jonas was talking about out of order execution in the cpu, not disk i/o.

Henry



More information about the fpc-pascal mailing list