[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Module suggestion: Atomic operations
From: |
Marc Nieper-Wißkirchen |
Subject: |
Re: Module suggestion: Atomic operations |
Date: |
Mon, 25 May 2020 09:03:55 +0200 |
Hi Bruno,
Am So., 24. Mai 2020 um 22:54 Uhr schrieb Bruno Haible <address@hidden>:
> 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