Hi Bruno, Am So., 24. Mai 2020 um 22:54 Uhr schrieb Bruno Haible <br...@clisp.org>:
> Yes, given that the platform support for these atomic types/operations is > increasing, it would accelerate the adoption if there was a Gnulib module, > like you describe it. Program developers could then adopt <stdatomic.h> > without losing portability to a number of platforms. So, you mean that Gnulib should try to provide <stdatomic.h> in case it is not available? I have to think about it whether this can ever work (and in an efficient way). When I raised the question, I was more thinking of a custom interface that abstracts both over <stdatomic.h> and some other implementation with explicit mutexes, much like the tls module abstracts over C11's TLS and some other implementations, like the pthread one. One problem with <stdatomic.h> as given is that atomic values have no destructors. Thus, we cannot simply attach locks to them in a pre-C11 implementation because there is no place to destroy the locks. Thus, we would have to work with a pool of locks shared by all atomic variables. But when to set up the pool? A module atomic with a header "atomic.h" could implement an interface that has destructors (which are mapped to no-ops when <stdatomic.h> is available). > Personally I'm not very motivated to work on that (because in most algorithms > I've seen, mutexes/locks are the way to go, and because I find the > memory_order > stuff hard to understand). But if you want to work on that, it will be > welcome! I should wait for the copyright assignment first. As for the memory_order things. A first version of the module may map everything to memory_order_seq_cst, which is safe but not always the most efficient. Marc