[fpc-devel] volatile variables

[Andrew Brunner]

> No, that is impossible. That's the whole point of using libraries such as
> libpthread. They abstract such issues away. Using atomic operations inside
> mutex sections only slows down your program unnecessarily (unless you also
> access the target memory location from code not guarded by that mutex, and
> also use atomic operations in those alternate cases -- or if you are using a
> synchronization primitive from a library that does not observe the same
> semantics as libpthread, but that would be a really strange design
> decision).

Two issues with what you are suggesting Jonas.

Issue 1.) libpthread is just a posix implementation.
it does not AUTOMATICALLY resolve issues inherent with present day
multi-core memory access with respect to cores.  It is by definition a
thread implementation that includes atomic locks.

Issue 2.) Telling people that it is poor design to exclude posix
threads implementation is ignorant.  FPC is cross platform.  Posix
threads specification is mainly to offer windows like threadding to
unix/linux flavors.

> If what you write above would be true, almost no program using libpthread
> for synchronization would consistently work on multi-core systems. How many
> programs do you know that exclusively use atomic operations to access shared
> memory locations inside code regions guarded by a pthread_mutex?

Access vs. Order.  This is what makes a variable volatile across cores
(not threads).