On Thu, 2017-01-05 at 20:30 +0100, Bruno Haible wrote: > Torvald Riegel wrote: > > IMHO, gnulib synchronization primitives should simply move towards the > > semantics chosen by C++11 and more recent (if you dislike C++ for some > > reason, just use the C++ semantics applied to C11; C is lacking behind > > in terms of preciseness of the specification). > > > > Of course you can build your own, but that requires expertise and time. > > gnulib is there to help adoption of POSIX and newer C standards. For > instance, with gnulib you could use <stdint.h> since 2004, long before > all platforms had it. (Even recently, in glibc 2.24, there was an issue > with SIZE_MAX in <stdint.h> on s390 architecture.) gnulib does its best > to shield its users from such portability problems. > > Regarding atomics, I agree it's good to have a standard in this area. > But I fear gnulib can do less than it does for <stdint.h>, because the > implementation is highly CPU and OS dependent. Just take a look at > GCC's libatomic...
C11 and C++11 also provide basic threading and synchronization primitives, for example mutexes and condvars. C++14 also has reader-writer locks. If you compare the semantics of these against POSIX, you'll see that they differ and that C/C++ often make less guarantees to programs, in particular regarding odd corner cases, which benefits a good design overall IMO.
