lkml.org 
[lkml]   [2008]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Replace completions with semaphores
    From
    Date
    On Tue, 2008-04-15 at 09:17 +0200, Bart Van Assche wrote:
    > On Tue, Apr 15, 2008 at 8:46 AM, Peter Zijlstra <peterz@infradead.org> wrote:
    > >
    > > On Tue, 2008-04-15 at 08:18 +0200, Bart Van Assche wrote:
    > > > Would it really be a good idea to give a synchronization concept that
    > > > behaves exactly like a semaphore another name than "semaphore" ? The
    > > > semaphore concept is well known and is taught in every computer
    > > > science course.
    > >
    > > Are the ramifications wrt priority inversion taught? Is it made clear
    > > that its hard to validate because there is no clear resource owner?
    > >
    > > Afaik, non of these subjects are touched upon in the CS-101 courses and
    > > that is exactly the problem. So you can say they are not well know, they
    > > are just widely misunderstood.
    > >
    > > And yes, if there are more hand a very few such users it doesn't make
    > > sense to keep them open coded.
    >
    > Regarding semaphores and priority inversion: I have never recommended
    > the use of semaphores over mutexes, all I recommended is to keep the
    > name "semaphore" for something that behaves like a semaphore. There
    > might be better ways to discourage the use of the semaphore API, e.g.
    > letting the compiler print a warning every time a semaphore function
    > is called unless one or another #define has been enabled.

    That sounds horrible; I really prefer targeted replacements like
    completions that make it clear what they're supposed to be used for.

    > Regarding priority inheritance: does the above mean that you consider
    > priority inheritance as an optimal solution for realizing real-time
    > behavior in the kernel ? Are you aware of the fundamental problems
    > associated with priority inheritance ? These issues are well explained
    > in Victor Yodaiken's paper "Against priority inheritance". See also
    > http://www.linuxdevices.com/files/misc/yodaiken-july02.pdf .

    Priority inheritance isn't ideal, but comming from a general purpose
    kernel that wasn't build from scratch to accomodate hard realtime its
    basically the only option.

    Also things like lockdep are a real help to a lot of developers - loads
    of locking bugs never make it into the kernel because of it.



    \
     
     \ /
      Last update: 2008-04-15 10:47    [W:2.826 / U:0.364 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site