From owner-freebsd-hackers Thu Dec 3 13:55:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA29529 for freebsd-hackers-outgoing; Thu, 3 Dec 1998 13:55:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA29522; Thu, 3 Dec 1998 13:55:40 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA15552; Thu, 3 Dec 1998 14:54:58 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd015461; Thu Dec 3 14:54:48 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA12692; Thu, 3 Dec 1998 14:54:39 -0700 (MST) From: Terry Lambert Message-Id: <199812032154.OAA12692@usr09.primenet.com> Subject: Re: Thread locking (was Re: cvs commit: src/include pthread.h src/lib/libc_r/uthread uthread_mattr_kind_np.c uthread_mutex.c) To: eivind@yes.no (Eivind Eklund) Date: Thu, 3 Dec 1998 21:54:39 +0000 (GMT) Cc: eischen@vigrid.com, hackers@FreeBSD.ORG, jb@FreeBSD.ORG, lists@tar.com In-Reply-To: <19981129210047.Z9226@follo.net> from "Eivind Eklund" at Nov 29, 98 09:00:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What does the P in Pthreads mean? > > Phenomenally stupid. Any standard that include locking and doesn't > allow definition of recursive locks fall within this category. You can implement recursive locks rather trivially; you protect modification of the lock list and the structures with non-recursive locks, however. Recursive lock programming implies stack state relationship cycles, so as far as I'm concerned, it's no great loss if the code has to be written with the knowledge of the calls it has already made, instead of investing that knowledge in the stack. Effectively, recursive locking is a crutch for programmers that don't know how to perform correct systems analysis and functional decomposition of programming problems. That's why WIN32 threads support both semaphore (recursive) and mutex (nonrecursive) lock types; WIN32 has a lot of those people programming against it. The UNIX style file lock coelescence is one of the most brain damaged attempts to save kernel memory ever attempted by man, since it is, in effect, a shadow of an hosted OS server (like SAMBA, CAP, NWU, etc.). > No - it is AFAIK a superset of the POSIX standard. It also require > that if we detect the deadlock condition we should return EDEADLK - > but we don't detect the case. Allowing a lock to be "re-aquired" by > the same thread just falls out of the code. Careful. Kernel threads requires changes to support this, since the pid between threads in the current implementation is not the same, whereas in a real implementation it should be. So there are other deadlocks that can bite you. 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-hackers" in the body of the message