From owner-acpi-jp@jp.freebsd.org  Wed Nov  7 01:47:30 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id BAA02511;
	Wed, 7 Nov 2001 01:47:30 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id BAA02505;
	Wed, 7 Nov 2001 01:47:24 +0900 (JST)
	(envelope-from robert.moore@intel.com)
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id QAA28278;
	Tue, 6 Nov 2001 16:47:17 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001110608483426475
 ; Tue, 06 Nov 2001 08:48:34 -0800
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VD69MC2X>; Tue, 6 Nov 2001 08:48:26 -0800
Message-ID: <B9ECACBD6885D5119ADC00508B68C1EA2FDFDD@orsmsx107.jf.intel.com>
From: "Moore, Robert" <robert.moore@intel.com>
To: "'John Baldwin'" <jhb@FreeBSD.org>,
        "Moore, Robert" <robert.moore@intel.com>
Cc: "Diefenbaugh, Paul S" <paul.s.diefenbaugh@intel.com>,
        Therien@clio.sc.intel.com, "Therien, Guy" <guy.therien@intel.com>,
        Grover@clio.sc.intel.com, "Grover, Andrew" <andrew.grover@intel.com>,
        acpi-jp@jp.FreeBSD.org, Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Date: Tue, 6 Nov 2001 08:47:05 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1444
Subject: [acpi-jp 1444] RE: ACPI CA  Mutex patches
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: robert.moore@intel.com


Release order matters if you have multiple threads using the mutexes.

To quote from the ACPI specification section for the Mutex object:

"To prevent deadlocks, wherever more than one synchronization object must be
owned, the synchronization objects must always be released in the order
opposite the order in which they were acquired."

The SyncLevel parameter to the Mutex object is intended to help enforce
this.

Bob


-----Original Message-----
From: John Baldwin [mailto:jhb@FreeBSD.org]
Sent: Tuesday, November 06, 2001 8:39 AM
To: Moore, Robert
Cc: Diefenbaugh, Paul S; Therien@clio.sc.intel.com; Guy;
Grover@clio.sc.intel.com; Andrew; acpi-jp@jp.FreeBSD.org; Mitsuru
IWASAKI
Subject: RE: [acpi-jp 1439] RE: ACPI CA Mutex patches



On 05-Nov-01 Moore, Robert wrote:
>     Method(TES4)
>     {
>             Acquire(MUT1, 0x500)
>             Acquire(MUT0, 0x500)
>             Release(MUT1)
>             Release(MUT0)           /* AE_AML_MUTEX_ORDER */
>     }

Why does release order matter?  In a typical mutex implementation, blocking
only occurs on a contested acquire.  Releases never block, so releases can
never result in deadlocks.

Briefly looking at the code, I agree that the CurrentSyncLevel belongs in
the
thread and not in the lock.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
