Mutexes/Locks in C: C11 `mtx_lock()` vs `pthread_mutex_lock()`

Question

Mutexes were not introduced to the C standard until C11, right? Now that they exist, which should one use or prefer, and when? Why? What are the differences?

C11's mtx_lock() vs pthread_mutex_lock():

1. C11's mtx_lock()
   1. From <threads.h>:
      1. https://en.cppreference.com/w/c/thread
      2. https://www.gnu.org/software/libc/manual/html_node/ISO-C-Mutexes.html
2. pthread_mutex_lock()
   1. From <pthread.h>:
      1. https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html
      2. https://man7.org/linux/man-pages/man3/pthread_mutex_lock.3p.html
   2. Stack Overflow: Mutex lock threads

It looks like <threads.h> is part of the C11 and later C standard, whereas <pthread.h> is a Posix standard provided by Linux directly? I don't have a good understanding of the history or ecosystem, or when to choose what, and why. It also makes me wonder: is <threads.h> part of any microcontroller compiler yet--ex: AVR, SAMD, or STM32? Ideally, whatever system I go with, I'd like it to work on Linux and microcontrollers, or even better: all operating systems, and microcontrollers.

Up to now I've done most locking on a computer in C++ using C++11's std::mutex, or on a microcontroller in C using FreeRTOS semaphores, or on a bare-metal microcontroller by turning interrupts and global interrupts on and off to protect volatile variables shared between ISRs and the main loop. Ex: on 8-bit AVR microcontrollers I use the ATOMIC_BLOCK() macros, which do just that. But, now I'm writing a fast_malloc() implementation in C and realized I don't even know how to use a mutex in C on a computer, so I began the above research and found the above links, and realized I don't know anything about pthread locks vs this new C11 mtx_lock().

Nessim

I think you answered the question already: pthread library is limited to POSIX systems – if you want to be fully portable, you should rather rely on C standard means. On the other hand, if you have no C11 available, you might need to fall back to OS-specific stuff. As you mention interrupts: Never ever acquire mutexes in interrupt (or signal) handlers, even if available (consider implementing a HW driver)! You risk immediate deadlock as interrupt handlers are not preempted and the thread holding the mutex, if interrupted, cannot give it back so that the ISR might continue running... – Phelps

Note that C11 threads have never caught on the way C++11 threads did, and many system libcs don't have support for them. For better or worse, it's generally better to use native pthreads or Windows threads instead. – Haemoid

I would recommend the standard threads over pthreads if the standard threads included a way to get the native thread handle/id. Instead I say: Do you need any functionality not available in the standard library? If not (and if your compiler supports it) - go for standard threads. If you do need functionality only available in pthreads, use pthreads. – Lavoie

@Phelps pthread library is limited to POSIX systems As C11 threads effectively are, given that MSVC is stuck at C89 and C11 threads are optional anyway. – Unsightly

@AndrewHenle, MSVC moved a lot towards standard C, recently. But I don't know if they include an implemenation of C11 threads. – Insult

@JensGustedt They seem to have gotten tired of being mocked for being stuck in 1989 when over 20% of the 21st century is already over. But when your bragging is all mealy-mouthed crap like "C11 and C17 are becoming supported language versions" instead of "C11 and C17 are now supported language versions" and then "While there is currently no support for any C11 optional features, we are committed to providing the most impactful optional features in future releases.", true commitment is lacking. – Unsightly

@AndrewHenle MSVC is not the only Windows compiler, though. Never been a fan of anyway, on/for windows always using MinGW, if allowed to... – Phelps