Hyperactive g_event thread

[Ivan Voras]

On 22 October 2010 20:46, Jaakko Heinonen <jh at freebsd.org> wrote:
> On 2010-10-22, Ivan Voras wrote:
>> Isn't this sequence:
>>
>> -     mtx_unlock(&g_eventlock);
>>       wakeup(&g_wait_event);
>> +     mtx_unlock(&g_eventlock);
>>
>> too racy? It is possible, especially if something changes in scheduling
>> or the wakeup() implementation, and on single-CPU machines, that the
>> woken thread could run and then encounter the lock not yet released,
>> leading to more lock waiting.
>
> As far as I have understood this is the normal way to protect against
> losing wakeups, no? wakeup(9) marks the sleeping process runnable and
> removes it from the sleep queue but doesn't force a context switch
> immediately. Thus increased lock contention would happen only if a
> context switch happens between wakeup() and mtx_unlock(). I don't see
> this a problem but please correct me if I am wrong.

I'm also not sure, just wanted to discuss the case. Maybe the
condvar(9) API would be better here? (but that is probably out of
scope for your patch, I'm just thinking aloud)