Hi Marc,
> 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.
Ah...
> Thus, we would have to work with a pool of locks shared by all atomic
> variables. But when to set up the pool?
Pools have the drawback that they add a configuration requirement on the
application: What is the default size of the pool? When to increase the
pool size? By how much? When to shrink the pool? The developer would have
determine good answers to this, but 5 years later or under specific
circumstances the answers may not be good enough. (*)
Therefore, I would avoid pools, unless strictly necessary for performance
reasons. And if you need pools already in the design phase, you've been
doing a mistake.
> 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).
Yes, that's the better way to approach it, then.
Bruno
(*) A very good example is the "pool of registers" design in the SPARC
architecture, with the sliding register windows. In the later SPARC
processors, they have been nothing but a source of complexity.
