[fpc-devel] volatile variables

[Hans-Peter Diettrich]

Andrew Brunner schrieb:
> On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell <mschnell at lumino.de> wrote:
>> On 06/28/2011 04:31 PM, Andrew Brunner wrote:
>>>  how developers
>>> can force code execution in order w/o using a third party library?
>> Execution in order only makes sense when there is another thread that relies
>> on this order.
> 
> Wrong.  Sigh... Order of execution is paramount just about everywhere.
>  It can be disastrous if not understood.
> Remember ***cores!=threads*** people.

If your experience is really that chaotic, I think it's worth some 
deeper investigation.

1) Can one thread be executed on multiple cores, at the same time?

If so, shouldn't there exist means (flags...) to tell the OS, that FPC 
executables are not (yet) ready for such automatic parallelism?

2) When a thread wanders around, from one core to another one, shouldn't 
be the starting conditions (CPU state, caches) exactly in the state when 
the thread was stopped on the previous core?

Isn't that effect caused by your monitor, that forces the thread into 
suspended state frequently?

You seem to assume that the cache of the previous core may contain some 
updated data, that was not yet written back into RAM when the thread is 
resumed on a different core, whose cache happens to contain other 
values? This really would be a very big problem :-(
[So big that I cannot believe that it really exists]

3) When above cache inconsistencies can occur, how can even a 
single-threaded program work correctly?

A little chance exists, that an thread moves so often between two cores, 
that both caches contain copies of the process-local data. But this 
never should cause trouble, because single-threaded code was never 
required to use Interlocked access to its private data.

3.1) Chances are higher for a multi-threaded application, where the 
caches can contain any number of copies of shared (main thread) memory 
areas.

But what would this mean to threaded code in general? I cannot believe 
that thread-aware code must use Interlocked access to *all* variables, 
even in the main thread, because no procedure can know from which thread 
it is actually called, in which core.


That said I have some doubts, regarding your conclusions. Can you run 
your test again, assuring that only one thread can access the list at 
the same time, but *without* the Interlocked updates?

DoDi