[fpc-devel] volatile variables

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Jun 28 16:59:17 CEST 2011


On 28 Jun 2011, at 16:28, Andrew Brunner wrote:

>> Jonas already pointed you to it:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
>>
>> "Applications shall ensure that access to any memory location by  
>> more than
>> one thread of control (threads or processes) is restricted such  
>> that no
>> thread of control can read or modify a memory location while  
>> another thread
>> of control may be modifying it."
>>
>> Please note the "read or modify".  If you fail to understand this,  
>> you can
>> read the source of a posix threads implementation, e.g. nptl (which  
>> is part
>> of libc).
>
> I honestly don't believe that by the above statement has anything to
> do with what we're talking about here.  And I'm thinking it's because
> of the two issues.
>
> One is threads.  One is cores.  I think we need to focus to get to the
> bottom of what we're all trying to say.

The Posix specification (and the Win32 api documentation referred to  
in this thread) doesn't care whether all threads are executed by the  
same or by different cores, and/or whether separate threads are  
rescheduled to different cores at different time slices. The specified  
behaviour is guaranteed to be the same under all circumstances exactly  
because it is defined at the level of "threads" rather than "cores".  
That's the whole point of having abstractions such as threads and  
specifying their behaviour.

Even if you would create a libpthread implementation that works on top  
of MPI and which distributes threads over an entire cluster of  
different machines, then still the same behaviour would have to be  
guaranteed (because the *threads* have to comply to the specified  
behaviour, not specifically pipelines, cores, processors, machines,  
accelerator cards, ...).


Jonas



More information about the fpc-devel mailing list