Also,
I have made some changes to my previous implementation of asm/atomic.h
Julian, please check
<https://github.com/vivek-roy/haiku/commit/b1b90b0201cfa8a1300d232762892cb6c56a8d11>
.
On Tue, Jun 20, 2017 at 1:10 AM, Vivek Roy <vivekroyandroid@xxxxxxxxx>
wrote:
How to check if a mutex is locked or not? For a mutex m, checking m.holder
!= NULL will work only in KDEBUG, right?
On Sun, Jun 18, 2017 at 5:37 PM, Hamish Morrison <hamishm53@xxxxxxxxx>
wrote:
On 18/06/2017 11:34, Vivek Roy wrote:
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
<https://www.freebsd.org/cgi/man.cgi?query=sx_slock&sektion=9>
Okay, trying to implement sx.
Thanks
There's no reason to use a read/write lock here. All that linux/mutex.h
provides is a simple mutex, not a read/write lock. Just because FreeBSD
have chosen to implement this with a rwlock doesn't mean we need to do the
same. We can just implement this with a regular mutex.
You can use the mutex from here to implement it:
http://cgit.haiku-os.org/haiku/tree/headers/private/kernel/lock.h