Re: signalling a condvar from inside vs. signalling a condvar von outside

On 4/15/2025 2:41 AM, Bonita Montero wrote:

Am 13.04.2025 um 23:40 schrieb Chris M. Thomasson:
 

You code is hard to read. ...

 The code is beautiful.

I can understand it, but, well, shit happens. I would not say it's beautiful... But, that is just me. Again, shit happens.

Signalling while locked or unlocked was an old debate. Think of signalling
while holding the lock. A thread gets woken and immediately sees that the
lock is held. Oh well. Wait morphing  can help with that. However, signal
outside when you can...

 The number of context-switches determined via getrusage() is twice per
loop iteration, i.e. on switch to the thread and one switch from the
thread; so everything is optimal with glibc.

In real applications there is generally more going on in those critical sections vs your test... Well, I have seen some horror shows in my life.
Again, think of a scenario where the lock is held. The thread signals... Another thread wakes up and has to instantly block on a wait morphing queue in the kernel. This is not "ideal". A signal outside of the mutex can be beneficial. Signalling outside can give a signaled thread a possible fast-path into the critical section, completely eliminating the need for kernel interaction. Now, an adaptive mutex can try to help with this via limited spinning... However, try to signal outside when you can.