[lkml]   [2005]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

    On Fri, 16 Dec 2005, Thomas Gleixner wrote:

    > On Thu, 2005-12-15 at 21:32 +0100, Geert Uytterhoeven wrote:
    > > > Why have the "MUTEX" part in there? Shouldn't that just be DECLARE_SEM
    > > > (oops, I mean DEFINE_SEM). Especially that MUTEX_LOCKED! What is that?
    > > > How does a MUTEX start off as locked. It can't, since a mutex must
    > > > always have an owner (which, by the way, helped us in the -rt patch to
    > > > find our "compat_semaphores"). So who's the owner of a
    > >
    > > No one. It's not really a mutex, but a completion.
    > Well, then let us use a completion and not some semantically wrong
    > workaround

    It is _not_ wrong to have a semaphore start out in locked state.

    For example, it makes perfect sense if the data structures that the
    semaphore needs need initialization. The way you _should_ handle that is
    to make the semaphore come up as locked, and the data structures in some
    "don't matter" state, and then the thing that initializes stuff can do so
    properly and then release the semaphore.

    Yes, in some cases such a locked semaphore is only used once, and ends up
    being a "completion", but that doesn't invalidate the fact that this is
    a perfectly fine way to handle a real issue.

    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: 2009-11-18 23:46    [W:0.020 / U:9.688 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site