Date: Thu, 3 Dec 1998 21:54:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: eischen@vigrid.com, hackers@FreeBSD.ORG, jb@FreeBSD.ORG, lists@tar.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) Message-ID: <199812032154.OAA12692@usr09.primenet.com> In-Reply-To: <19981129210047.Z9226@follo.net> from "Eivind Eklund" at Nov 29, 98 09:00:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812032154.OAA12692>