public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Daniel Walker <dwalker@mvista.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>,
	linux-acpi@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	len.brown@intel.com, robert.moore@intel.com
Subject: Re: [PATCH 1/3] acpi: add real mutex function calls
Date: Mon, 21 Jul 2008 21:20:23 +0200	[thread overview]
Message-ID: <4884E177.5000809@linux.intel.com> (raw)
In-Reply-To: <1216648574.2294.9.camel@dhcp32.mvista.com>

Daniel Walker wrote:
> On Mon, 2008-07-21 at 09:51 +0800, Zhao Yakui wrote:
>> On Sat, 2008-07-19 at 11:16 -0700, Daniel Walker wrote:
>>> Instead of re-using semaphores for the mutex operation, I've
>>> added usage of the kernel mutex for the os mutex implementation.
>>>
>> What is the advantage that the kernel mutex is used for the ACPI mutex
>> implementation instead of using semaphore?
>> And it seems that too much ACPICA source code is touched.
> 
> In general you would want to use a mutex whenever your using mutex-like
> semantics. If I see a mutex used in code then I have a pretty good idea
> the locking is sane..

With a mutex the locking can be totally broken and with a semaphore the 
locking can be completely fine. They are both just tools which can be 
used correctly and also incorrectly.

The main advantage of mutexes is that they can be slightly more 
efficient (doesn't matter for the ACPI case, the ACPI interpreter is not 
performance critical) and that they are easier to check with lockdep. 
But there are also other considerations like in ACPICA's case portability.

My feeling is that adding own semaphore wrappers to ACPICA wouldn't
be an improvement. Defering to Bob Moore for his opinion, since
he maintains ACPICA.

-Andi

  reply	other threads:[~2008-07-21 19:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-19 18:16 [PATCH 0/3] acpi: acpi: sem out, mutex/completion in Daniel Walker
2008-07-19 18:16 ` [PATCH 1/3] acpi: add real mutex function calls Daniel Walker
2008-07-19 18:16   ` [PATCH 2/3] acpi: semaphore removal Daniel Walker
2008-07-19 18:16     ` [PATCH 3/3] Add lockdep integration for the ACPI mutex usage Daniel Walker
2008-07-20  8:15     ` [PATCH 2/3] acpi: semaphore removal Dave Chinner
2008-07-20 14:49       ` Daniel Walker
2008-07-21  1:51   ` [PATCH 1/3] acpi: add real mutex function calls Zhao Yakui
2008-07-21  9:14     ` Peter Zijlstra
2008-07-21  9:17       ` Andi Kleen
2008-07-21  9:24         ` Peter Zijlstra
2008-07-21 19:15           ` Andi Kleen
2008-07-21 19:33             ` Peter Zijlstra
2008-07-21 19:55               ` Matthew Wilcox
2008-07-21 20:22                 ` Daniel Walker
2008-07-21 20:00               ` Andi Kleen
2008-07-21 20:38                 ` Daniel Walker
2008-07-21 13:59         ` Daniel Walker
2008-07-21 13:56     ` Daniel Walker
2008-07-21 19:20       ` Andi Kleen [this message]
2008-07-21 19:39         ` Daniel Walker
2008-07-23 22:14           ` Moore, Robert
2008-07-24 12:44             ` Daniel Walker

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=4884E177.5000809@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=dwalker@mvista.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=robert.moore@intel.com \
    --cc=yakui.zhao@intel.com \
    /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