lkml.org 
[lkml]   [2011]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC -v3 PATCH 2/3] sched: add yield_to function
    On 01/05/2011 04:39 AM, KOSAKI Motohiro wrote:
    > > On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
    > > > Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
    > > > avoid almost Nehalem (and other P2P cache arch) lock unfairness
    > > > problem. (probaby creating pthread_condattr_setautoyield_np or similar
    > > > knob is good one)
    > >
    > > Often, the thread calling pthread_cond_signal() wants to continue
    > > executing, not yield.
    >
    > Then, it doesn't work.
    >
    > After calling pthread_cond_signal(), T1 which cond_signal caller and T2
    > which waked start to GIL grab race. But usually T1 is always win because
    > lock variable is in T1's cpu cache. Why kernel and userland have so much
    > different result? One of a reason is glibc doesn't have any ticket lock scheme.
    >
    > If you are interesting GIL mess and issue, please feel free to ask more.

    I suggest looking into an explicit round-robin scheme, where each thread
    adds itself to a queue and an unlock wakes up the first waiter.

    --
    error compiling committee.c: too many arguments to function



    \
     
     \ /
      Last update: 2011-01-05 09:39    [W:3.101 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site