[haiku-gsoc] Re: Implementation Queries

  • From: Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>
  • To: <haiku-gsoc@xxxxxxxxxxxxx>
  • Date: Sun, 18 Jun 2017 11:39:22 +0200

Hey,


On 18.06.2017 10:05, Vivek Roy wrote:



    atomic_cmpset_int() can be implemented using gcc's
    __atomic_compare_exchange() with memorder set to __ATOMIC_RELAXED.
    atomic_load_acq_int() can use gcc's __atomic_load() with memorder
    set to __ATOMIC_ACQUIRE.

atomic_cmpset_int and atomic_load_acq_int were called from inside atomic_cmpxchg. So instead of having a macro for them I made a macro for atomic_cmpxchg using __atomic_compare_exchange_n as you can see here <https://github.com/vivek-roy/haiku/blob/9026ac8d45499d16e78b16058ba580467e9fbe3d/headers/compatibility/linuxkpi/asm/atomic.h#L60> (and things work fine).

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).


Next comes mutex. I hope the mutex implemented in src/libs/compat/freebsd_network/compat/sys/mutex.h will be good enough.
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

Regards
Julian

Other related posts: