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

[Andrew Brunner]

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.
>
> In fact, using atomic operations won't help to solve that problem, you do
> need memory barriers to flush the memory writes (most pthread functions and
> ending a pthread guarantee memory barrier behaviour, which is why WaitFor()
> itself is safe).
>
> On x86 you're unlikely to encounter many problems because of the strongly
> consistent memory model, but at least x86-64 now also has read and write
> barrier instructions. On non-x86 architectures, you definitely need memory
> barriers in such cases.
>

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 or are you saying that the boolean array needs to be
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.