user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
   As WAITING is set, it calls the kernel; but instead of processing
   this immediately, the thread is suspended for any reason (locks,
   reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
   which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
   It sees the WAITING flag is not set, so it returns at once,
   having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
   flag, and returns from the kernel. Now we have a mutex theoretically
   held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
   is not set. We now have one lock owned by two separate threads.
   That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>

headers/private/kernel/user_mutex.h

@@ -17,7 +17,7 @@ void		user_mutex_init();
 
 status_t	_user_mutex_lock(int32* mutex, const char* name, uint32 flags,
 				bigtime_t timeout);
-status_t	_user_mutex_unlock(int32* mutex, uint32 flags);
+status_t	_user_mutex_unblock(int32* mutex, uint32 flags);
 status_t	_user_mutex_switch_lock(int32* fromMutex, int32* toMutex,
 				const char* name, uint32 flags, bigtime_t timeout);
 status_t	_user_mutex_sem_acquire(int32* sem, const char* name, uint32 flags,

headers/private/system/syscalls.h

@@ -77,7 +77,7 @@ extern ssize_t		_kern_wait_for_objects(object_wait_info* infos, int numInfos,
 /* user mutex functions */
 extern status_t		_kern_mutex_lock(int32* mutex, const char* name,
 						uint32 flags, bigtime_t timeout);
-extern status_t		_kern_mutex_unlock(int32* mutex, uint32 flags);
+extern status_t		_kern_mutex_unblock(int32* mutex, uint32 flags);
 extern status_t		_kern_mutex_switch_lock(int32* fromMutex, int32* toMutex,
 						const char* name, uint32 flags, bigtime_t timeout);
 extern status_t		_kern_mutex_sem_acquire(int32* sem, const char* name,

headers/private/system/user_mutex_defs.h

@@ -6,7 +6,7 @@
 #define _SYSTEM_USER_MUTEX_DEFS_H
 
 
-// user mutex specific flags passed to _kern_user_mutex_unlock()
+// user mutex specific flags passed to _kern_mutex_unblock()
 #define B_USER_MUTEX_UNBLOCK_ALL	0x80000000
 	// All threads currently waiting on the mutex will be unblocked. The mutex
 	// state will be locked.