From owner-acpi-jp@jp.freebsd.org  Wed Nov  7 04:54:12 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id EAA09401;
	Wed, 7 Nov 2001 04:54:12 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id EAA09394
	for <acpi-jp@jp.freebsd.org>; Wed, 7 Nov 2001 04:54:11 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 4804 invoked from network); 6 Nov 2001 19:54:09 -0000
Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender <jhb@FreeBSD.org>)
          by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <iwasaki@jp.FreeBSD.org>; 6 Nov 2001 19:54:09 -0000
Message-ID: <XFMail.011106115409.jhb@FreeBSD.org>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20011107.042534.92590451.iwasaki@jp.FreeBSD.org>
Date: Tue, 06 Nov 2001 11:54:09 -0800 (PST)
From: John Baldwin <jhb@FreeBSD.org>
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Cc: paul.s.diefenbaugh@intel.com, guy.therien@intel.com,
        andrew.grover@intel.com, robert.moore@intel.com,
        acpi-jp@jp.freebsd.org
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1449
Subject: [acpi-jp 1449] Re: ACPI CA Mutex patches
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: jhb@FreeBSD.org


On 06-Nov-01 Mitsuru IWASAKI wrote:
> Hi, John.
> 
>> >From a theory standpoint, there's no reason to bother caring about release
>> orders, just acquire orders.
> 
> I was thinking of deadlock cases.  How about this?
> 
>     Mutex(MTX0, 0)
>     Mutex(MTX1, 0)
> 
>     Method(DLCK)
>     {
>         Acquire(MTX0, 0xffff)
>         Acquire(MTX1, 0xffff)
>         Release(MTX0)
> 
>         Sleep(10000)    /* the processor maybe relinquished */
> 
>         Acquire(MTX0, 0xffff)
>         Release(MTX0)
>         Release(MTX1)
>     }
> 
> If more than one thread invoke this method at almost the same time,
> the first thread maybe stuck at Acquire(MTX0) after Sleep(), the
> second stuck at Acquire(MTX1) and other threads stuck at Acquire(MTX0)...
> Is my understanding correct?

The release is not the problem.  Acquiring MTX0 while holding MTX1 is the
problem.  A Release can not block. In order to deadlock, you have to have
threads blocked against each other.  Only Acquire's can block, thus it follows
that Acquires are all you have to worry about.

This is how Witness works in the FreeBSD kernel.  It only builds its state and
performs checks on lock acquires.  The only thing we do for a lock release is
update our internal bookkeeping, but we don't perform any order checks. 
Witness is a bit more complicated because it builds its tree of dependencies on
the fly, whereas ACPI defines a static dependency list via the the sync levels.
All ACPI has to do is ensure that when you acquire a Mutex of level X, you
don't currently hold any other Mutexes of Level X or higher.  If you keep the
list of mutexes you hold in a list sorted by SyncLevel, this becomes a very
simple O(1) check since you just have to check the first item in the list. 
Keeping the list sorted is in fact very easy since you acquire them in sorted
order.

> Thanks

-- 

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/
