From owner-freebsd-arch Fri Oct 13 2:16:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id BCCC237B502; Fri, 13 Oct 2000 02:16:36 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id CAA02621; Fri, 13 Oct 2000 02:14:58 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAAcnaOff; Fri Oct 13 02:14:52 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id CAA22883; Fri, 13 Oct 2000 02:16:21 -0700 (MST) From: Terry Lambert Message-Id: <200010130916.CAA22883@usr09.primenet.com> Subject: Re: we need atomic_t To: jasone@canonware.com (Jason Evans) Date: Fri, 13 Oct 2000 09:16:20 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), cp@bsdi.com (Chuck Paterson), msmith@FreeBSD.ORG (Mike Smith), arch@FreeBSD.ORG In-Reply-To: <20001012214446.H11949@canonware.com> from "Jason Evans" at Oct 12, 2000 09:44:46 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Here's one of Butenhof's example programs, which uses POSIX threads: [ ... technically illegal program that uses structure assignment ... ] That's still technically illegal, since it assumes that a mutex is merely a value in implementation, instead of potentially something that lives on a linked list which is tracked to ensure against deadlocks (for instance). For example, if you initialized a mutex as "held", the witness code wouldn't work without additional initialization. If that's the case (which it is), then really you have three choices. One is to use an initializer function, like the draft 4 POSIX stuff. A second is to throw out the witness code. The third is to make a postinitialization pass, and use it to further post-process all preinitialized mutexes onto the lists: this really begs the question of "if you have to call a function anyway, why not make the function do everything, and make the interface that much less cryptic?". I personally think that disallowing recursion, and keeping a "held mutex count" in a variable in the struct representing the holder (the proc, interrupt, trap, or kthread context) would be enough, along with asserts, to ensure against deadlocks. This would not prevent holding two mutex at the same time, but you would have to go out of your way to fudge the holder's count, so it could still be used for assertion. Of course, I still personally believe that a mutex is not the same thing as a semaphore or a lock, so that's just my opinion on how to make things safe. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message