Lock-free ping-pong in C11 - c

Question

I'm very new to concurrency in C and trying to do some basic staff to understand how it works.
I wanted to write a conforming implementation of lock-free ping-pong, i.e. one thread prints ping, after that another thread prints pong and make it lock-free. Here is my attempt of that:
#if ATOMIC_INT_LOCK_FREE != 2
#error atomic int should be always lock-free
#else
static _Atomic int flag;
#endif
static void *ping(void *ignored){
while(1){
int val = atomic_load_explicit(&flag, memory_order_acquire);
if(val){
printf("ping\n");
atomic_store_explicit(&flag, !val, memory_order_release);
}
}
return NULL;
}
static void *pong(void *ignored){
while(1){
int val = atomic_load_explicit(&flag, memory_order_acquire);
if(!val){
printf("pong\n");
atomic_store_explicit(&flag, !val, memory_order_release);
}
}
return NULL;
}
int main(int args, const char *argv[]){
pthread_t pthread_ping;
pthread_create(&pthread_ping, NULL, &ping, NULL);
pthread_t pthread_pong;
pthread_create(&pthread_pong, NULL, &pong, NULL);
}
I tested it a few times and it worked, but there are things that seems weird:
It either lock-free or does not compile
Since the Standard defines lock-free property to be equal to 2 in order all operations on the atomic type are always lock-free. In particular I checked the compile code and it looks as
sub $0x8,%rsp
nopl 0x0(%rax)
mov 0x20104e(%rip),%eax # 0x20202c <flag>
test %eax,%eax
je 0xfd8 <ping+8>
lea 0xd0(%rip),%rdi # 0x10b9
callq 0xbc0 <puts#plt>
movl $0x0,0x201034(%rip) # 0x20202c <flag>
jmp 0xfd8 <ping+8>
This seems ok and we don't even need some sort of fence since Intel CPUs does not allow stores to be reordered with earlier loads. Such assumptions works only in case we know the hardware memory model which is not portable
Using stdatomics with pthreads
I'm stuck with glibc 2.27 where threads.h is not yet implemented. The question is if it is strictly-conforming to do so? Anyway this is sort of strange if we have atomics, but do not have threads. What is the conforming usage of stdatomics in multithreaded application then?

Answer 1

There are 2 meanings to the term lock-free:
the computer science meaning: one thread getting stuck can't impede the others. This task is impossible to make lock-free, you need the threads to wait for each other. (https://en.wikipedia.org/wiki/Non-blocking_algorithm)
using lockless atomics. You're basically creating your own mechanism for making a thread block, waiting in a nasty spin-loop with no fallback to give up the CPU eventually.
The individual stdatomic load and store operations are each separately lock-free, but you're using them to create sort of a 2-thread lock.
Your attempt looks correct to me. I don't see a way a thread can "miss" an update, because the other thread won't write another one until after this one finishes. And I don't see a way for both threads to be inside their critical sections at once.
A more interesting test would be using unlocked stdio operations, like
fputs_unlocked("ping\n", stdio); to take advantage of (and depend on) the fact that you've already guaranteed mutual exclusion between threads. See unlocked_stdio(3).
And test with output redirected to a file, so stdio is full buffered instead of line-buffered. (A system call like write() is fully serializing anyway, like atomic_thread_fence(mo_seq_cst).)
It either lock-free or does not compile
Ok, why is that weird? You chose to do that. It's not necessary; the algorithm would still work on C implementations without always-lock-free atomic_int.
atomic_bool might be a better choice, being lock-free on more platforms including 8-bit platforms where int takes 2 registers (because it has to be at least 16-bit). Implementations are free to make atomic_bool a 4-byte type on platforms where that's more efficient, but IDK if any actually do. (On some non-x86 platforms, byte loads / stores cost an extra cycle of latency to read/write in cache. Negligible here because you're always dealing with the inter-core cache miss case.)
You'd think atomic_flag would be the right choice for this, but it only provides test-and-set, and clear, as RMW operations. Not plain load or store.
Such assumptions works only in case we know the hardware memory model which is not portable
Yes, but this no-barriers asm code gen only happens while compiling for x86. Compilers can and should apply the as-if rule to create asm that runs on the compile target as if the C source was running on the C abstract machine.
Using stdatomics with pthreads
Does the ISO C Standard guarantee the atomic's behavior to be well-defined with all threading implementations (like pthreads, earlier LinuxThreads, etc...)
No, ISO C has nothing to say about language extensions like POSIX.
It does say in a footnote (not normative) that lockless atomics should be address-free so they work between different processes accessing the same shared memory. (Or maybe this footnote is only in ISO C++, I didn't go and re-check).
That's the only case I can think of ISO C or C++ trying to prescribe behaviour for extensions.
But the POSIX standard hopefully says something about stdatomic! That's where you should look; it extends ISO C, not the other way around, so pthreads is the standard that would have to specify that its threads work like C11 thread.h and that atomics work.
In practice of course, stdatomic is 100% fine with any threading implementation where all threads share the same virtual address space. This includes non-lock-free things like _Atomic my_large_struct foo;.