[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