Am 07.07.2012 01:58, schrieb Joshua Maurice:
No, this is misleading. volatile alone is not sufficient to warrant data
consistency between threads, but is necessary. volatile and _Atomic are
complementary specifications that *both* are needed if you want to make
sure that a thread always uses the latest stored value of a variable. If
you have
static int _Atomic a = ATOMIC_VAR_INIT(23);
if (tester)
for (;
printf("current value is %d\n", a);
The compiler is allowed to change the loop into something equivalent to
{
int tmp = a; // do an atomic_load operation here
for (;
printf("current value is %d\n", tmp);
}
and thus always print the same value.
static int _Atomic volatile a = ATOMIC_VAR_INIT(23);
would assure that each execution of printf would see an updated value.
C11 mutexes (as are POSIX mutexes) are much too heavy machinery where a
simple atomic would suffice. I think that atomics and the precise data
consistency model are the real novelty in C11 (and C++1). That is to
That was my thinking. The POSIX mutex api is really kind of awkward,
and on Linux the underlying implementation is more complicated than it
has to be. Currently I'm developing on x86_64 and x86, and I chose to
use "lock incl %0" and then inspect the result to detect collisions.
It is obviously very fast, and I can control how long a thread will
spin on the lock before sleeping. I have yet to investigate whether I
need to use a different instruction for the 64-bit arch.
A compiler supported atomic type would allow the removal of the
minimal inline asm that I'm using, but I can keep it to preserve some
backward compatibility with older systems.
provide a possibility of communicating safely between different threads
(and with signal handlers) without relying on OS support (or almost).
One potential application for non-mutex locking structures occurs in
some virtualized environments. Under the Xen hypervisor, it is
possible to share virtual memory segments between guest domains. The
facility is called 'grant pages', and looks a little like a SYSV
shared memory segment to the application. With such a memory window,
a ring buffer (or equivalent algorithm) can allow inter-domain
communications without any system calls. The same goes, of course,
for a ring-buffer instantiated in SYSV shared memory, but that is
limited to communications between processes on the same host.
Compared to TCP/IP IPC, this should greatly improve the available IPC
bandwidth among virtualized hosts on a multi-core platform.
I haven't yet got to the point of integrating support for Xen in any
of my code, but it's on my todo list.
Regards,
Uncle Steve
