Hi Bruno, Am Mo., 25. Mai 2020 um 09:24 Uhr schrieb Bruno Haible <br...@clisp.org>:
> 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. (*) For general types, the gcc (and clang) implementations use general locks coming from a pool. (In the gcc case, see libatomic and, especially, libat_lock_n.) Nevertheless, I agree with you that a pool is suboptimal. > Yes, that's the better way to approach it, then. There is one problem with providing some emulation with Posix locks, though. At least one type in <stdatomic.h> is guaranteed to be lock-free, the atomic flag. Since C18, it can be used in signal handlers, where Posix locks won't work because they are not async-safe. Moreover, <stdatomic.h> provides memory fences, which I don't know how to emulate in general and which also seem to be crucial in signal handlers of multithreaded applications. It seems to me that a substitute of <stdatomic.h> needs to know a bit about the underlying compiler (so that builtins can be used) or the underlying architecture (for example, x86 does not need memory fences with the release or acquire memory order. Unfortunately, my knowledge about other compilers than gcc or other architectures than x86 is limited. I could provide the skeleton of a substitute, but it would need other people to add their architectures. Marc
