From owner-freebsd-hackers Thu Oct 26 12:40:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19764 for hackers-outgoing; Thu, 26 Oct 1995 12:40:40 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA19757 for ; Thu, 26 Oct 1995 12:40:36 -0700 Received: from JIMI.MIT.EDU by MIT.EDU with SMTP id AA27668; Thu, 26 Oct 95 15:39:50 EDT Received: by jimi.MIT.EDU (5.57/4.7) id AA07699; Thu, 26 Oct 95 15:40:28 -0400 Message-Id: <9510261940.AA07699@jimi.MIT.EDU> To: Richard Toren Cc: hackers@freebsd.org, proven@MIT.EDU Subject: Re: A quick vote on pthreads PLZ In-Reply-To: Your message of "Sat, 21 Oct 1995 21:32:39 EDT." Date: Thu, 26 Oct 1995 15:40:27 EDT From: Christopher Provenzano Sender: owner-hackers@freebsd.org Precedence: bulk > Has the FPU save/restore been fixed in pthreads recently? Yes. > > With the locking in the libraries, what will the gratutious mutex locking > cost in time if the app is not threaded? For the most part it shouldn't be noticable. (There are a few exceptions namely getc()/putc()) In general mutexes are cheap, debugging race conditions isn't. > > Just some food for thought. I have used pthreads since this summer to > practice threaded code analysis and construction, but I knew it was just > a package, and had limitations. If it is advertised as being part of the > OS, (and possibly POSIX) wil lit mislead people? I hope not, but to be safe a non threaded one should be provided. It will take time to hammer out the bugs such that the threaded one will be as reliable as the non threaded one. CAP