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: Resizing hash tables in Guile Date: Wed, 12 Feb 2003 18:47:48 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87lm0o7951.fsf@alice.rotty.yi.org> <1044889242.1033.310.camel@localhost> <1044984847.1032.419.camel@localhost> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045072765 1207 80.91.224.249 (12 Feb 2003 17:59:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2003 17:59:25 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18j0xu-0007sU-00 for ; Wed, 12 Feb 2003 18:46:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j0zU-0006hZ-07 for guile-devel@m.gmane.org; Wed, 12 Feb 2003 12:48:12 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18j0zC-0006em-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 12:47:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18j0zA-0006ZY-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 12:47:54 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j0zA-0006YL-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 12:47:52 -0500 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=linnaeus) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18j0z7-0007Lf-00; Wed, 12 Feb 2003 18:47:49 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18j0z6-0000Lo-00; Wed, 12 Feb 2003 18:47:48 +0100 Original-To: Marius Vollmer In-Reply-To: (Marius Vollmer's message of "12 Feb 2003 12:41:24 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: djurfeldt@nada.kth.se X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1919 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1919 Marius Vollmer writes: > Roland Orre writes: > >> > I made the hash tables thread-safe (locking/unlocking a mutex at hash >> > table access and rehashing). Is that good? An alternativ is to >> > require of the programmer to make sure the hash tables aren't accessed >> > in parallel. >> >> In our case I think we will most likely set up the different processes >> to use different hash tables but we have still not parallellized our >> applications. Could/should the mutex protection maybe be optional? > > Since users must consciously ask for resizable hash tables, we can > require them to do the locking themselves. Should we? I would say > yes, since people need to be aware of thread issues anyway, and maybe > they have a better scheme for ensuring thread safe access to a hash > table. I agree. When implementing the current thread safety I've encountered a cluster of very interesting problems. I'll write up a small text about this, put in the workbook and post on the list. I'd say I can do this within a few weeks. For example, I've discovered that the with-mutex construct we provide in threads.scm is of dubious utility. It also seems hard to second-guess the "users" needs when trying to provide high-level thread-safety constructs in general. I'll remove the thread protection code from hashtab.c. > Removing the locking from the core code should improve performance, > right? Yes, at least marginally. > However, the hash tables should be somewhat thread safe: they might > not work as advertised when multiple threads access them, but the > application might not crash. That is, adding an element from one > thread while another thread is doing the same thing might make one of > the elements disappear, but it must leave the hash table in a valid > state. > > Do the non-resizing hash tables behgave that way, incidentally? I'd say yes. > (Ahh, I just love cooperative threading. These things are so much > easier and efficient when there is only one running thread with > defined switch points... :-) I think the current restriction on signals only causing exceptions at well defined points takes us a good way towards that. I doubt that there are still many points in Guile which need to be modified to get the thread safety to where we want it. M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel