From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: GH replacement proposal (includes a bit of Unicode) Date: Mon, 17 May 2004 23:30:42 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87brkmn3lp.fsf@zagadka.ping.de> References: <877jw87hjv.fsf@trouble.defaultvalue.org> <87pt9yzjdi.fsf@ivanova.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084830749 21877 80.91.224.253 (17 May 2004 21:52:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 21:52:29 +0000 (UTC) Cc: guile-devel@gnu.org, Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 17 23:52:21 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 1BPq20-0001Iu-00 for ; Mon, 17 May 2004 23:52:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPpwH-0007rw-Us for guile-devel@m.gmane.org; Mon, 17 May 2004 17:46:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPpkP-0005ko-8X for guile-devel@gnu.org; Mon, 17 May 2004 17:34:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPph9-00057w-F8 for guile-devel@gnu.org; Mon, 17 May 2004 17:31:22 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPph8-00057D-0z for guile-devel@gnu.org; Mon, 17 May 2004 17:30:46 -0400 Original-Received: from dialin.speedway45.dip121.dokom.de ([195.138.45.121] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1BPpjr-0003J8-00 for guile-devel@gnu.org; Mon, 17 May 2004 23:33:36 +0200 Original-Received: (qmail 8713 invoked by uid 1000); 17 May 2004 21:30:42 -0000 Original-To: Andreas Rottmann In-Reply-To: <87pt9yzjdi.fsf@ivanova.rotty.yi.org> (Andreas Rottmann's message of "Fri, 23 Apr 2004 19:36:41 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 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:3732 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3732 Andreas Rottmann writes: > Marius Vollmer writes: > >>> I'm a little wary of the locking, especially global locking, but I >>> suppose it may well be necessary. I don't have a strong feeling >>> either way offhand, but presuming for the moment that it is necessary, >>> then is there any way to lock down a particular value rather than the >>> entire heap? >> >> Having a lock for every object would have a high overhead and give you >> very little in terms of performance, I guess. Also, they would be >> tricky to use. >> > Why would the overhead be significantly larger than for one object? > Pika will have per-object locks, and I think the implementation chosen > has little overhead over global locking. Ahh, I don't know about that implementation. How large is the overhead? (in bits/object, say. URL perfectly OK.) >> When you need to lock two objects, there would be the danger of >> deadlocks, when other code needs to lock the exact same two objects, >> but does it in reverse order. >> > You could probably solve this by having an poeration that does an > "atomic" lock of serveral objects. Naive algorithm: > > 1) lock all objects you can > 2) if that's all: > fine > else: > release all objects locked previously, wait a bit and goto 1) Yes, but I would count this as 'significant overhead' ;-) >> You would also have to allow locking an object twice, further >> increasing overhead. >> > Why do you need to lock an object twice? You don't need to, but you can't avoid, in general (I think). The might be some code path that locks one object twice without anyone intending this. But, yeah, you can partition your code into two kinds, just like with a single global lock: When you have locked some objects, you can't call functions that lock more objects. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel