On 08.05.2020 14:12, Joerg Sonnenberger wrote: > On Thu, May 07, 2020 at 11:09:03PM +0200, Kamil Rytarowski wrote: >>> (1) They introduce non-trivial blocking conditions, often defeating the >>> reason for using atomics in first place. >>> (2) They don't work in a constrained environment and are broken by >>> common UNIX primitives like memory mapped IO or shared memory. >>> (3) They are not async signal safe. >>> >> >> None of the above corner cases is a real world issue. If we would care >> about them, we would forbid using many other standard features such as >> floating point numbers... just because in corner cases they are not >> reliable. > > OK, I'll stop here. It is clear that you are not willing to engage in > any meaningful discussion as your position is set in stone already and > facts are meaningless. For the record, my objection stands. > > Joerg > OK. You are trying to criticise C/C++/... atomics for things that are not promised by them AND are used in real world. Still atomics can wrap hardware assisted atomic accesses and tell to users whether this occurs. With _Atomic() we can mark any arbitrary struct to have serialized accesses. As I said, with your attitude we shall remove FPU support (and softfloat) as they are not async safe, not safe in virtualization for MMU accesses and more just to mention 2 issues.
Description: OpenPGP digital signature