Is the expected behaviour of the atomic_cmpxchg() documented anywhere? I'm
wondering why you chose the memory orderings the way you did there. If they
are not right it will lead to either performance degradation (if they are
too strict) or to subtle concurrency bugs (if they are too relaxed).
If you check the actual implementation here
<https://github.com/vivek-roy/haiku/blob/9026ac8d45499d16e78b16058ba580467e9fbe3d/headers/compatibility/linuxkpi/asm/atomic.h#L152>,
it is expected to return the old value if the value of the pointer is not
changed to the new value, thus __ATOMIC_ACQUIRE for failure_memorder, and
if the value of the pointer is same as expected then the value has to be
acquired, changed and then released, thus __ATOMIC_ACQ_REL for
success_memorder. So I did what I did.
That one implements a normal mutex, FreeBSD's sx is short for
shared/exclusive-lock, another name for a read/write-lock. According to [0]
they have a few specialties regarding their scheduling. You could try and
implement them using the Haiku kernel's rw_lock (see
headers/private/shared/locks.h), although it might be necessary to take a
close look at differences in behaviour. Also, our rw_lock doesn't implement
all the functions of FreeBSD's sx, such as try-to-lock, so it needs to be
seen of those are being used in the code you're compiling.
[0] https://www.freebsd.org/cgi/man.cgi?query=sx_slock&sektion=9
Okay, trying to implement sx.
Thanks
