lkml.org 
[lkml]   [2005]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
> > > DEFINE_SEM_MUTEX_LOCKED?
> >
> > 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.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.169 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site