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

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Oct 8 16:52:39 CEST 2010


On 08 Oct 2010, at 16:33, Andrew Brunner wrote:

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



More information about the fpc-pascal mailing list