Date: Tue, 20 Oct 98 17:06:19 -0500 From: "Richard Seaman, Jr." <lists@tar.com> To: "Jason Evans" <jasone@canonware.com> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Another Serious libc_r problem Message-ID: <199810202206.RAA15321@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Tue, 20 Oct 1998 13:16:07 -0700 (PDT), Jason Evans wrote: >Did you actually run the code? No. >The point I was trying to make is that the >code does _not_ deadlock for the default (fast mutex). Yes, I missed your point. >I'm not sure that >this is a bug, but it is different than the behavior I've seen on other >systems. Can someone say whether this is allowed by the POSIX spec? It is my impression that the X/Open XSH5 standard allows the default mutex type to be implementation dependent. The "NORMAL" type, equivalent to "fast", should not do error checking and not report deadlocks from recursion, and should hang if a thread tries to lock a mutex it owns. However, DEFAULT does not have to be NORMAL. As to the POSIX spec, I'm not positive. Butenhof's book "Programming with POSIX Threads" states (page 52): "You cannot lock a mutex when the calling thread already has that mutex locked. The result ... may be an error return (EDEAKLK), or it may be a self-deadlock." I believe that Butenhof intended his book to describe the POSIX 1003.1c-1995 standard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810202206.RAA15321>