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: scm_i_fraction_reduce thread safety Date: Fri, 30 Jan 2004 09:45:28 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <3FD85844.3060108@ccrma> <1071170342.1217.60.camel@flare> <87wu91mxhf.fsf@zip.com.au> <87k73z1la9.fsf@zagadka.ping.de> <87ad4ve61r.fsf@zip.com.au> <87hdz3xocn.fsf@zagadka.ping.de> <87zncuat0g.fsf@zip.com.au> <87ektukw66.fsf@zagadka.ping.de> <1074654679.3851.30.camel@flare> <4016E30B.4060207@dirk-herrmanns-seiten.de> <874quhdlfm.fsf@raven.i.defaultvalue.org> <87ekti7dka.fsf@zagadka.ping.de> 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 1075474621 13634 80.91.224.253 (30 Jan 2004 14:57:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2004 14:57:01 +0000 (UTC) Cc: Marius Vollmer , guile-devel@gnu.org, djurfeldt@nada.kth.se, Carl Witty , Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 30 15:56:35 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 1Ama4R-0006M8-00 for ; Fri, 30 Jan 2004 15:56:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AmZy1-00088Y-5o for guile-devel@m.gmane.org; Fri, 30 Jan 2004 09:49:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AmZvd-0006vq-DT for guile-devel@gnu.org; Fri, 30 Jan 2004 09:47:29 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AmZuX-00065K-PZ for guile-devel@gnu.org; Fri, 30 Jan 2004 09:46:53 -0500 Original-Received: from [213.212.20.77] (helo=kvast.blakulla.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AmZuL-0005se-Ud for guile-devel@gnu.org; Fri, 30 Jan 2004 09:46:10 -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 1AmZtp-0004zv-00; Fri, 30 Jan 2004 15:45:37 +0100 Original-Received: from mdj by chunk with local (Exim 4.30) id 1AmZtg-000414-89; Fri, 30 Jan 2004 09:45:28 -0500 Original-To: Marius Vollmer In-Reply-To: <87ekti7dka.fsf@zagadka.ping.de> (Marius Vollmer's message of "Thu, 29 Jan 2004 20:35:49 +0100") 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:3334 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3334 Marius Vollmer writes: > Rob Browning writes: > >> In any case, do we have a "current plan" with respect to threading, There is a document threads/thread-interface.text in workbook which is not a plan, but which brings up things which should be considered when making decisions on the organization of threading in Guile. > I don't have one ready, but I do very much want to have one before > 1.8. I need to decide for myself whether I would want to go for full > concurrency or for restricting us to a one-thread-at-a-time model. > > Full concurrency is not a nice-model to program for, > one-thread-at-a-time wont be able to take advantage of multiple > processors. My view is that the current organization of threading in HEAD has a lot of promise. It does give full concurrency, at the same time as it is usually quite easy to program for. For the application writer or Guile user who doesn't want to concern himself with threading there is nothing special to think about. For those who do write threaded programs, there *could* be a distinction between thread-safe and thread unsafe resources. They would need to use mutecis etc explicitly in the latter case. However, usually, there is not much to think about even at the C level. Since the garbage collector, in the current scheme, only can be invoked at special well-defined places in the code, there is nowadays not even a need for the SCM_DEFER/ALLOW_INTS critical sections. Many of those in the current code can simply be removed. I know what I'm talking about here since I have written threaded applications using HEAD. Two have been using gtk-1.2, with an event handler thread, and multiple threads accessing the graphics. I think the highest demands is put on the Guile developers, because there are probably quite a few parts of Guile which we probably would like to have the ambition to make thread-safe (although we wouldn't need to in all cases). But even in this case, we shouldn't exaggerate the problem. Basically, the main thing to look out for is when we have code which changes the state of something which is available for other threads. That doesn't happen too often. There could of course turn up tricky problems with regard to threaded semantics in areas such as signals and exceptions. On the other hand, I think the benefits of allowing full pthreads support are great. Among other roles, Guile is an application extension language. I think it is up to the application writer to decide which thread library he wants to use, so I'd like to see Guile being able to support various thread libraries, the choice being made at Guile initialization time. (These things are discussed in the thread-interface.text document mentioned above.) If the application writer have chosen pthreads, I wouldn't say the downside of removing full concurrency is only with regards to multi-CPU support. What is almost more important is the constraints that will cause on the design of the application. The application writer will then be limited with respect to the designs he can choose between. For example, if we don't support full concurrency, the application writer can't easily write Scheme extensions (Scheme primitives) which run concurrently. (This statement may or may not be true depending on the exact form of the restriction you are thinking about.) Also, supporting pthreads without full concurrency on the Scheme side will likely introduce more overhead than we have now in HEAD because of all arbitration using mutecis and condition variables that would entail. Finally, while multi-CPU support may look exotic now, it's not unlikely that it will become a common thing in within just a few years once the hardware makers eventually run into the long-predicted barriers for making things faster along the current route. I think it would be sad to build ourselves into a corner in this respect... M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel