channel send() condition variable lock ordering

[zevv]

I'm trying to get my multi threaded Nim programs running clean with valgrind and thread sanitizers, and this one has been bothering as it always generates a warning from helgrind:

The condition variable in channel send() is signalled without holding the lock; this is techncally not incorrect, but it might lead to spurious wakeups. It could be that the original author ordered the unlock and signal purposely for performance reasons, but I have no way of telling from the code.

Can anyone with more knowledge on this subject look at this?

pthread_cond_signal() documentation states:

"The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal()."

Funny, but I have no clue what "predictable scheduling behavior" is supposed to mean in this context.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 79b25a9

Hint: mm: orc; opt: speed; options: -d:release
165158 lines; 11.616s; 614.562MiB peakmem