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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
