From: Arjan van de Ven <arjan@infradead.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, torvalds@osdl.org,
arjanv@infradead.org, nico@cam.org, jes@trained-monkey.org,
zwane@arm.linux.org.uk, oleg@tv-sign.ru, dhowells@redhat.com,
alan@lxorguk.ukuu.org.uk, bcrl@kvack.org, rostedt@goodmis.org,
hch@infradead.org, ak@suse.de, rmk+lkml@arm.linux.org.uk
Subject: Re: [patch 0/9] mutex subsystem, -V4
Date: Thu, 22 Dec 2005 14:23:49 +0100 [thread overview]
Message-ID: <1135257829.2940.19.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <20051222050701.41b308f9.akpm@osdl.org>
> > * - only one task can hold the mutex at a time
> > * - only the owner can unlock the mutex
> > * - multiple unlocks are not permitted
> > * - recursive locking is not permitted
> > * - a mutex object must be initialized via the API
> > * - a mutex object must not be initialized via memset or copying
> > * - task may not exit with mutex held
> > * - memory areas where held locks reside must not be freed
>
> Pretty much all of that could be added to semaphores-when-used-as-mutexes.
> Without introducing a whole new locking mechanism.
this is basically in direct conflict with what Linus has been asking
for.. "leave semaphore semantics alone".
I agree with Linus that if it has very different rules, it should have a
different name.
> Ingo, there appear to be quite a few straw-man arguments here. You're
> comparing a subsystem (semaphores) which obviously could do with a lot of
> fixing and enhancing with something new which has had a lot of recent
> feature work out into it.
>
> I'd prefer to see mutexes compared with semaphores after you've put as much
> work into improving semaphores as you have into developing mutexes.
semaphores have had a lot of work for the last... 10 years. To me that
is a sign that maybe they're close to their limit already.
You keep saying 10 times "so please enhance semaphores to do this".
Semaphores have far more complex rules for the slowpath (mutex semantics
are simple because the number of wakers is always at most one, and if
you hold the lock, you KNOW nobody else can do another release under
you). Adding dual rules or other complexity to it doesn't sound too
compelling to me actually; they're highly tricky things already (just
look at the i386 ones.. that extra wakeup was there to plug a hole (at
least that is my empirical conclusion based on "we remove it it hangs"
behavior).
Having 2 sets of behaviors for the same primitive also sounds not good
to me to be honest, that's bound to explode stuff left and right all the
time.
I realize you're not looking forward to a gradual conversion; yet Linus
says he doesn't want a wholesale change either but wants it gradual.
next prev parent reply other threads:[~2005-12-22 13:23 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 11:41 Ingo Molnar
2005-12-22 11:53 ` Christoph Hellwig
2005-12-22 12:45 ` Ingo Molnar
2005-12-22 15:34 ` Nicolas Pitre
2005-12-22 15:40 ` Ingo Molnar
2005-12-22 16:32 ` Nicolas Pitre
2005-12-22 16:44 ` Ingo Molnar
2005-12-22 16:58 ` Russell King
2005-12-22 21:04 ` Ingo Molnar
2005-12-22 21:26 ` Russell King
2005-12-22 21:27 ` Nicolas Pitre
2005-12-22 21:37 ` [patch 1/2] mutex subsystem: basic per arch fast path primitives Nicolas Pitre
2005-12-22 21:53 ` Christoph Hellwig
2005-12-22 21:40 ` [patch 2/2] mutex subsystem: use the per architecture fast path lock_unlock defines Nicolas Pitre
2005-12-22 21:54 ` [patch 0/9] mutex subsystem, -V4 Ingo Molnar
2005-12-22 16:58 ` Nicolas Pitre
2005-12-22 17:20 ` Christoph Hellwig
2005-12-22 17:33 ` Steven Rostedt
2005-12-22 18:24 ` Nicolas Pitre
2005-12-22 11:54 ` Andrew Morton
2005-12-22 12:20 ` Ingo Molnar
2005-12-22 13:07 ` Andrew Morton
2005-12-22 13:23 ` Arjan van de Ven [this message]
2005-12-22 13:44 ` Andrew Morton
2005-12-22 14:11 ` Alan Cox
2005-12-22 23:30 ` Andrew Morton
2005-12-22 23:34 ` Christoph Hellwig
[not found] ` <32801.10.10.10.28.1135295357.squirrel@linux1>
2005-12-22 23:49 ` Sean
2005-12-22 23:53 ` Randy.Dunlap
[not found] ` <50572.10.10.10.28.1135296023.squirrel@linux1>
2005-12-23 0:00 ` Sean
2005-12-23 0:00 ` Steven Rostedt
[not found] ` <20051222221311.2f6056ec.akpm@osdl.org>
2005-12-23 14:24 ` Nicolas Pitre
2005-12-23 14:51 ` Andrew Morton
2005-12-23 14:57 ` Russell King
2005-12-23 15:04 ` Xavier Bestel
2005-12-23 15:27 ` Andrew Morton
2005-12-23 15:00 ` Steven Rostedt
2006-01-03 17:54 ` Abhijit Bhopatkar
2005-12-25 16:08 ` Roman Zippel
2005-12-25 22:54 ` Ingo Molnar
2005-12-26 21:49 ` Roman Zippel
2005-12-25 23:04 ` Andrew Morton
2005-12-25 23:22 ` Ingo Molnar
2005-12-26 10:35 ` Andrew Morton
2005-12-26 10:42 ` Arjan van de Ven
2005-12-26 11:11 ` Andrew Morton
2005-12-26 17:15 ` Mike Galbraith
2005-12-26 17:44 ` Lee Revell
2005-12-27 0:32 ` David Lang
2005-12-26 18:15 ` Linus Torvalds
2005-12-27 14:42 ` Ingo Molnar
2005-12-27 23:02 ` Andrew Morton
2005-12-26 0:33 ` Moore's law (was Re: [patch 0/9] mutex subsystem, -V4) Pavel Machek
2006-01-05 15:30 ` Andi Kleen
2006-01-05 19:08 ` Pavel Machek
2005-12-26 15:29 ` [patch 0/9] mutex subsystem, -V4 Nicolas Pitre
2005-12-22 15:46 ` Thomas Gleixner
2005-12-22 17:40 ` Linus Torvalds
2005-12-22 20:09 ` Steven Rostedt
2005-12-22 17:17 ` Christoph Hellwig
2005-12-22 15:19 ` Nicolas Pitre
2005-12-22 21:43 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1135257829.2940.19.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@infradead.org \
--cc=bcrl@kvack.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=jes@trained-monkey.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nico@cam.org \
--cc=oleg@tv-sign.ru \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=rostedt@goodmis.org \
--cc=torvalds@osdl.org \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®