From: Eric Wong Date: 2018-08-20T20:05:44+00:00 Subject: [ruby-core:88577] Re: [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed eregontp@gmail.com wrote: > normalperson (Eric Wong) wrote: > > (*) Along those lines, I think the "lock" idiom for GVL is not > > ideal for performance (kosaki rewrote the GVL for 1.9.3 to > > optimize for contention as a result). I might try replacing > > the GVL with a platform-independent scheduler which limits > > parallelism to the data structures the GVL currently protects. > > I don't follow, which data structures would the scheduler protect? > Internal VM data structures but not e.g. Ruby Hash? Everything the GVL currently protects, including the Ruby Hash. > > Note: This will NOT solve the parallelism problem which > > exists in C Ruby; that is a much bigger task (but still > > doable with a scheduler, and perhaps even more so). > > Now I am curious, how would a scheduler solve the > lack of parallelism at the Ruby level in CRuby? It might allow cheaper entry/exit for blocking regions; so we can use more blocking regions to achieve parallelism. GVL release/acquire is expensive at the moment; so there's places where we hold the GVL (e.g. readdir calls) and sacrifice parallelism when dealing with slow filesystems. Also, pthread_cond_wait is just like ConditionVariable#wait in that it must re-lock the mutex after sleeping. This re-lock can be contended, and it should not be necessary if we move away from condvars for some platforms (Linux and win32). The signaller (FUTEX_WAKE/SetEvent) can remove from the waitqueue while it's holding the lock, so the sleeper won't have to. Anyways, just a small idea in my head and totally unproven. Unsubscribe: