From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Universally-unique gensyms Date: Thu, 19 Jan 2012 07:25:28 +0100 Organization: Organization?!? Message-ID: <87zkdknr8n.fsf@fencepost.gnu.org> References: <87hazu1msh.fsf@netris.org> <87ehuyh1nf.fsf@pobox.com> <87ipk9zba2.fsf@netris.org> <87d3agu1rt.fsf@gnu.org> <87y5t4ejkz.fsf@pobox.com> <87d3agy4g1.fsf@netris.org> <87hazspjv7.fsf@fencepost.gnu.org> <87wr8owb2b.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1326954350 10495 80.91.229.12 (19 Jan 2012 06:25:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Jan 2012 06:25:50 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 19 07:25:47 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RnlRS-0001bh-Nt for guile-devel@m.gmane.org; Thu, 19 Jan 2012 07:25:46 +0100 Original-Received: from localhost ([::1]:43896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnlRS-0001Ph-6o for guile-devel@m.gmane.org; Thu, 19 Jan 2012 01:25:46 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:56529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnlRP-0001PY-0J for guile-devel@gnu.org; Thu, 19 Jan 2012 01:25:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RnlRN-000336-Lc for guile-devel@gnu.org; Thu, 19 Jan 2012 01:25:42 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnlRN-000332-9s for guile-devel@gnu.org; Thu, 19 Jan 2012 01:25:41 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RnlRL-0001Yg-7g for guile-devel@gnu.org; Thu, 19 Jan 2012 07:25:39 +0100 Original-Received: from p508ed97a.dip.t-dialin.net ([80.142.217.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Jan 2012 07:25:39 +0100 Original-Received: from dak by p508ed97a.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Jan 2012 07:25:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ed97a.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:oVYiEu9ceHY9ES5yyo0Oo1DgM3k= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13581 Archived-At: Mark H Weaver writes: > David Kastrup writes: > >> Mark H Weaver writes: >> >>> Andy Wingo writes: >>> >>>> Sorry for asking a stupid question, but why is it that we want the >>>> gensym counter to be thread-local? Just to avoid the mutex? TBH I >>>> don't think it's that big of a point of contention. This risks >>>> devolution into bike-shed-landia tho... >>> >>> It's a reasonable question. I don't feel strongly about it, but I >>> prefer lock-free programming where practical, and in this case there's >>> really no need for coordination between threads. Indeed, these UUIDs >>> are already designed to avoid collisions between multiple _sessions_ >>> without coordination. So why bother with the lock? >> >> To avoid both threads reading the same seed value before generating the >> same number? I have not looked at the code, but that could be a reason >> for serializing. > > Hence the _thread-local_ gensym counters, which is what we're > discussing. Please read before you post. And there is no problem if one thread initializes its gensym counter from the random source without locking at the same time another thread is in the middle of initializing its gensym counter. It does not appear to me that there is any locking that would prevent both ending up with the same random value. -- David Kastrup