Date: Fri, 13 Oct 2000 09:16:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jasone@canonware.com (Jason Evans) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), cp@bsdi.com (Chuck Paterson), msmith@FreeBSD.ORG (Mike Smith), arch@FreeBSD.ORG Subject: Re: we need atomic_t Message-ID: <200010130916.CAA22883@usr09.primenet.com> In-Reply-To: <20001012214446.H11949@canonware.com> from "Jason Evans" at Oct 12, 2000 09:44:46 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010130916.CAA22883>