rdos wrote:
The code is incomprehensible.
Seriously? Seems to me the code is pretty explicit about what it is doing.
rdos wrote:
It easy to understand that btr will set a bit and return the original value in CY.
Yes, if you read the CPU manual.
rdos wrote:
The C code is a hack that you have to analyse to understand what it actually does,
Not if you read the spec on cppreference or anywhere else. So not all that different from your assembler code. It's just newer.
rdos wrote:
and there is no guarantee it will be translated to lock-free code, if the atomic_fetch_and function even is supported.
Nothing is certain except death and taxes. However, anything claiming C11 support has a macro to test both of these questions (__STDC_NO_ATOMICS__ and ATOMIC_INT_LOCK_FREE, respectively). And I can guarantee that atomic_fetch_and runs on more platforms than your "btr" instruction. Oh, but it won't work with your beloved OpenWatcom, right? Well, not all of us hobble ourselves in this way.
rdos wrote:
Particularly with lock-free code, there is a need to understand how it operates and make sure it can handle all possible cases. If the code is incomprehensible, this analysis becomes impossible to.
I'm sorry, but atomic_fetch_and() does exactly what it says on the tin. If it was the explicit version, and the programmer was messing about with memory orders, then I would understand your apprehension, but this is the bog-standard sequential consistency version. So you get the same semantics on a weakly ordered system as on x86.