> Date: Sat, 1 Feb 2025 18:03:41 +0100 > From: Stephan <stephan...@googlemail.com> > > > By the way: Does khs->khs_waiters exist only as a micro-optimization > > for the wakeup path? > > > > if (__predict_false(khs->khs_waiters)) > > cv_signal/broadcast(cv); > > The khs_waiters field of the structure is important when a semaphore > is deleted. > > All threads waiting on it are notified and check the state of the > semaphore.
OK, in that case you do have a good reason to maintain the khs_waiters member and can't delete it altogether. > If it was deleted, all threads unlock the mutex and just go away > except the last one, which needs to call a function bringing the > semaphore back to a free state. > > The whole code can be found here: > > https://github.com/stephanwib/src/blob/trunk/sys/kern/uipc_hsem.c So you do have one case of the micro-optimization I suggested ditching, in khsem_release: 231 if (khs->khs_waiters) 232 cv_signal(&khs->khs_cv); https://github.com/stephanwib/src/blob/bf7fe621d136783c573db970f7135f690b361a28/sys/kern/uipc_hsem.c#L231-L232 You can just delete line 231 here. > This API is very close to what is found on BeOS/Haiku and is of course > part of my effort to make Haiku software run on NetBSD. Cool! I wonder if we should consider having a compat_haiku.
