Re: How to wait on cv_timedwait() correctly

> Date: Sat, 1 Feb 2025 18:03:41 +0100
> From: Stephan <[email protected]>
> 
> > 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.