bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C11 atomics


From: Torvald Riegel
Subject: Re: C11 atomics
Date: Thu, 05 Jan 2017 21:18:59 +0100

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]