[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] New locking primitive for 2.5
    On Thu, Feb 07, 2002 at 09:57:35PM +0100, Daniel Phillips wrote:
    > On February 7, 2002 09:36 pm, wrote:
    > > > P.S. If this is going to turn into another priority-inheritance flame, I
    > > > am stopping here. Let's take it off-list or just drop it, please. I'd
    > > > much prefer to discuss the current combilock issue which is at hand. ;)
    > >
    > > It's the same issue.
    > Not necessarily, look at Ingo's observation about replacing semaphores with
    > combi-locks as opposed to replacing spinlocks with combi-locks.

    The underlying issue is an attempt to find a magic trick that will make
    hard synchronization problems go away. The result is usually something that
    makes hard synchronization problems more obscure. Ingo points to a case,
    apparently triggered only by a wierd benchmark artefact where a queue of very
    short term operations builds up a queue of expensive process reschedules. The
    problem is that the same semaphore is used to for slow and fast operations
    and the solution is to split them apart somehow or to conclude that its not
    an important case.

    As Ingo points out, you need some actual positive results here, not a plausibility

    Victor Yodaiken
    Finite State Machine Labs: The RTLinux Company.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:18    [W:0.021 / U:7.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site