Clang Goes Ahead And Enables C11 By Default

[gilboa]

Forgive me for asking an apparently stupid question but why not simply use posix threads? Sure, in Windows you'll have to use CRT or win32 threads but the semantics are very similar.

[nanonyme]

Forgive me for asking an apparently stupid question but why not simply use posix threads? Sure, in Windows you'll have to use CRT or win32 threads but the semantics are very similar.

Because it's nice to have to write as little platform-specific code as possible

[san_dehesa]

Forgive me for asking an apparently stupid question but why not simply use posix threads? Sure, in Windows you'll have to use CRT or win32 threads but the semantics are very similar.

Let me reply that with the words of Jens Gustedt. (I am quoting from here on):

Perhaps people still underestimate the usefulness of C threads:

• They have simpler interfaces, no ?attributes? for mutexes or condition variables and alike.
• They come with well-defined atomic data types and operations. All modern architectures support this feature in one form or another, and up to now we only had access to that through awful assembler hacks.
• They allow for a different memory model without stack sharing between threads.
• They can also be implemented in non-POSIX operating systems, such as in the formerly dominant desktop OS, or on embedded systems, maybe even on ?bare metal?.
• They have no model for thread cancellation.

Especially the first two make it a very attractive thread API for simple parallel programming experiences, including for teaching. The lack of cancellation is an important property, too. ... To state it bluntly, I found the POSIX model insane: it has three different flows of events that interact with each other in unexpected ways:

1. The first level is relatively simple, mutexes. Operations on mutexes give a strictly synchronized flow of events between all threads that use the same mutex. Good.
2. Condition variables darken the picture a bit. We all know that to go into a wait on a condition variable a thread has to hold the mutex in question. So waiting synchronizes well with the other operations on the mutex. Unfortunately, to wake up other threads by signal or broadcast we are not required to hold the mutex. So, for each condition variable there is another flow of events for each thread that uses it, that is not synchronized with the events on the mutex.
3. Add cancellation to that picture to obtain a real mess. We have a third type of events that are triggered by a thread that might have nothing to do with the condition variable or the mutex. A nightmare, to keep track of a ?happened before? relation, to keep data structures consistent, to implement at all. All this for a feature that is rarely used and even less understood by programmers.

So, overall my hope is that C threads may gain more momentum and that a thread model that is a bit saner, more user-friendly and that reflects the properties of modern hardware will prevail.

----- Finish quote

If you want to check his full article, go to his article on musl.

[curaga]

Of course it's then a nitpick that way more platforms support posix threads than C11 threads, and many of those will never get C11 threads. Who cares, that's platform-specific!

[gilboa]

Let me reply that with the words of Jens Gustedt. (I am quoting from here on):

Perhaps people still underestimate the usefulness of C threads:

• They have simpler interfaces, no ?attributes? for mutexes or condition variables and alike.
• They come with well-defined atomic data types and operations. All modern architectures support this feature in one form or another, and up to now we only had access to that through awful assembler hacks.
• They allow for a different memory model without stack sharing between threads.
• They can also be implemented in non-POSIX operating systems, such as in the formerly dominant desktop OS, or on embedded systems, maybe even on ?bare metal?.
• They have no model for thread cancellation.

Especially the first two make it a very attractive thread API for simple parallel programming experiences, including for teaching. The lack of cancellation is an important property, too. ... To state it bluntly, I found the POSIX model insane: it has three different flows of events that interact with each other in unexpected ways:

1. The first level is relatively simple, mutexes. Operations on mutexes give a strictly synchronized flow of events between all threads that use the same mutex. Good.
2. Condition variables darken the picture a bit. We all know that to go into a wait on a condition variable a thread has to hold the mutex in question. So waiting synchronizes well with the other operations on the mutex. Unfortunately, to wake up other threads by signal or broadcast we are not required to hold the mutex. So, for each condition variable there is another flow of events for each thread that uses it, that is not synchronized with the events on the mutex.
3. Add cancellation to that picture to obtain a real mess. We have a third type of events that are triggered by a thread that might have nothing to do with the condition variable or the mutex. A nightmare, to keep track of a ?happened before? relation, to keep data structures consistent, to implement at all. All this for a feature that is rarely used and even less understood by programmers.

So, overall my hope is that C threads may gain more momentum and that a thread model that is a bit saner, more user-friendly and that reflects the properties of modern hardware will prevail.

----- Finish quote

If you want to check his full article, go to his article on musl.

Having the better part of the last 5 years developing a large cross platform and cross user/kernel space abstraction library - including large chunks of ugly CPU and platform specific assembly code, I must admit that I relate with some of his arguments. E.g. I can certainly agree with the claim that POSIX conditions are a mess.
However, threads and mutexes are complex beasts, there are huge difference between the different OS' and/or implementations. Using C11 will undoubtedly force least-common-denominator approach that will most likely lead to sloppy coding.
Win32 threads behave radically different than POSIX threads (E.g. Start a thread from DLLMain and you'll understand). Mutexes and Critical sections mean different things in Win32 and *both* behave completely different than POSIX mutexes.
Now, one must remember that C is usually used for low-level development (Kernel, high-end servers, etc) - places in which not-so-subtle difference between POSIX thread priority and Win32 thread priority actually mean something...

- Gilboa