From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: pthread fast mutexes Date: Mon, 23 Feb 2004 17:22:47 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87ishxv6m5.fsf@zip.com.au> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1077575125 3043 80.91.224.253 (23 Feb 2004 22:25:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Feb 2004 22:25:25 +0000 (UTC) Cc: djurfeldt@nada.kth.se Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 23 23:25:16 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AvOVn-0006EG-00 for ; Mon, 23 Feb 2004 23:25:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AvOVi-0005em-ED for guile-devel@m.gmane.org; Mon, 23 Feb 2004 17:25:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AvOUa-0005cZ-F7 for guile-devel@gnu.org; Mon, 23 Feb 2004 17:24:00 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1AvOU3-0005Fy-Bz for guile-devel@gnu.org; Mon, 23 Feb 2004 17:23:59 -0500 Original-Received: from [213.212.20.77] (helo=kvast.blakulla.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AvOU2-0005Et-Qp for guile-devel@gnu.org; Mon, 23 Feb 2004 17:23:26 -0500 Original-Received: from chunk.mit.edu ([18.42.2.92] helo=chunk ident=Debian-exim) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 1AvOTz-0005pQ-00; Mon, 23 Feb 2004 23:23:23 +0100 Original-Received: from mdj by chunk with local (Exim 4.30) id 1AvOTZ-0006YJ-Mr; Mon, 23 Feb 2004 17:22:57 -0500 Original-To: guile-devel@gnu.org In-Reply-To: (Mikael Djurfeldt's message of "Mon, 23 Feb 2004 17:05:16 -0500") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3441 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3441 Mikael Djurfeldt writes: > Therefore, fast mutexes are consistent with the requirements of the > interface, and they are, well, fast... Actually, there's more to it than that: Guile has two kinds of mutexes: 1. The ones you get with (make-mutex) These are efficient. They are also used internally and in the application C API. Therefore, any speed penalty on these will have a global effect on all programs in a Guile with threading activated. I actually did a benchmark between fast and normal mutexes and there is a significant difference in run-time for non-threaded programs in such a Guile. 2. The ones you get with (make-fair-mutex) These are fair, recursive and error checking. Simply put: These are the mutexes with all bells and whistles. Try (unlock-mutex (make-fair-mutex)) Given that we really need very efficient mutexes in Guile internals, and that one probably would like to be able to use these from the Scheme level if we also provide a "safe" alternative, I really wouldn't like to abstain from the "fast" mutexes of pthreads. If people think it is a really bad idea not to have better error checking on the mutexes you get from (make-mutex), one possibility is to make the following name substitutions: make-mutex --> make-fast-mutex make-fair-mutex --> make-mutex M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel