[fpc-devel] volatile variables

[Jonas Maebe]

On 28 Jun 2011, at 22:25, Hans-Peter Diettrich wrote:

> Andrew Brunner schrieb:
>> 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?

Not unless a speculative parallel execution environment is used  
(either in software or hardware), but because of their speculative  
nature those are by design transparent to the software (and afaik all  
of them are still only in research stages).

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

Such flags don't exist because there is no need for them.

> 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?

Yes. That is the job of the operating system (which will do this by  
inserting memory barriers, cache flushes etc).

> 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]

Indeed, it does not exist, unless there is a bug in the kernel of his  
machine.

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

Indeed.


Jonas