From owner-freebsd-hackers Sun Apr 26 16:52:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06415 for freebsd-hackers-outgoing; Sun, 26 Apr 1998 16:36:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04228 for ; Sun, 26 Apr 1998 16:11:26 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id JAA14150; Mon, 27 Apr 1998 09:10:43 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804262310.JAA14150@cimlogic.com.au> Subject: Re: threads performance In-Reply-To: <199804262104.OAA24424@usr05.primenet.com> from Terry Lambert at "Apr 26, 98 09:04:22 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 27 Apr 1998 09:10:43 +1000 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] 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 Terry Lambert wrote: > 4) Is he depending on the C++ STL? If so, he needs the one > from the Moscow Center for SPARC Computing, and he needs > some additional patches (that haven't been committed, since > STL is not widely supported in FreeBSD) to make it work > with a Draft 4 pthreads (specifically, STL assumes that you > can statically initialize mutexes, which is wrong). FWIW, -current has support for static mutexes (draft 10). To fix the performance problem that people are seeing, I'll fix the signal handling to use a single set of sigactions for the process (as POSIX says) and dispatch signals immediately without using a thread as the signal handler (this was a bad idea from the beginning, but it was coded before the standard was released). This will mean that a signal handler won't need to call any functions which require locks, so these can be changed to simple spinlocks (with sched_yield) instead of using the (kernel) sigmask to make things atomic. It is the repeated calls to change (or check) the sigmask that are the killer as far as I can tell, but it depends on what the application is doing as to whether they get noticed. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message