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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>