From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Locks and threads Date: Thu, 26 Mar 2009 10:10:36 +0100 Message-ID: <87bprotzsj.fsf@gnu.org> References: <87mycsd2rj.fsf@arudy.ossau.uklinux.net> <87vdqovofz.fsf@arudy.ossau.uklinux.net> <87vdqhc4oi.fsf@arudy.ossau.uklinux.net> <87mybrwqmj.fsf@arudy.ossau.uklinux.net> <87iqmfwohh.fsf@arudy.ossau.uklinux.net> <871vt1w81o.fsf@arudy.ossau.uklinux.net> <87zlf9qjgb.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1238058683 18708 80.91.229.12 (26 Mar 2009 09:11:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Mar 2009 09:11:23 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 26 10:12:39 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LmldY-0005co-2Q for guile-devel@m.gmane.org; Thu, 26 Mar 2009 10:12:32 +0100 Original-Received: from localhost ([127.0.0.1]:59732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmlcA-0007o5-Lu for guile-devel@m.gmane.org; Thu, 26 Mar 2009 05:11:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lmlby-0007lz-Rz for guile-devel@gnu.org; Thu, 26 Mar 2009 05:10:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lmlbt-0007k8-Ks for guile-devel@gnu.org; Thu, 26 Mar 2009 05:10:54 -0400 Original-Received: from [199.232.76.173] (port=38405 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lmlbs-0007jt-Pq for guile-devel@gnu.org; Thu, 26 Mar 2009 05:10:48 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:54782 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lmlbs-0008HY-E0 for guile-devel@gnu.org; Thu, 26 Mar 2009 05:10:48 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lmlbq-0002cs-Um for guile-devel@gnu.org; Thu, 26 Mar 2009 09:10:46 +0000 Original-Received: from 193.50.110.227 ([193.50.110.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Mar 2009 09:10:46 +0000 Original-Received: from ludo by 193.50.110.227 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Mar 2009 09:10:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 86 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.50.110.227 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 6 Germinal an 217 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) Cancel-Lock: sha1:5D1uTncUSGjuFiHCXcA9y/7Gn6A= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8325 Archived-At: Hi Neil, Neil Jerram writes: > - it runs for a duration specified by environment variable > GUILE_TEST_DEFINE_RACE_DURATION > > - it defaults to just 10s if that variable isn't defined. Even 10s is going to be slightly annoying. Another option would be to create tens of guile-definer threads instead of just 4; it might trigger the problem earlier. > #2 makes the symbols hash thread-safe, and it appears that this > completely fixes the define-race problem. I don't understand why we > apparently don't need patch #3 as well - but that's what my results > indicate. Roughly #2 is a specialized version of #3 as it addresses only the case of the symbol hash table. So it should be enough for this very problem. #3 is probably the way to go in the longer run, but it changes the API/ABI so it can't go in 1.8. I'll skip #3 for now. > * test-suite/standalone/test-define-race.c: New test. Could you run `indent' on this file? > +TESTS += test-define-race It needs to be conditionalized on `--with-threads'. > scm_i_rehash (SCM table, > unsigned long (*hash_fn)(), > void *closure, > - const char* func_name) > + const char* func_name, > + scm_i_pthread_mutex_t *mutex) This function assumes that MUTEX is locked. I would either write it prominently in a comment above or change the semantics so that MUTEX is acquired in `scm_i_rehash ()', not in the caller. The latter might be achieved by integrating tests about whether TABLE needs to be rehashed into `scm_i_rehash ()' itself. I.e., this: if (SCM_HASHTABLE_N_ITEMS (table) < SCM_HASHTABLE_LOWER (table) || SCM_HASHTABLE_N_ITEMS (table) > SCM_HASHTABLE_UPPER (table)) scm_i_rehash (...); would become: scm_i_rehash (...); I haven't reviewed all uses to see whether it's actually possible and whether it would lead to race conditions, though. > -static SCM symbols; > +SCM scm_i_symbols; I don't think this is needed, is it? > +static SCM > +intern_symbol (SCM symbol, const char *name, size_t len, size_t raw_hash) Since all users of `intern_symbol ()' perform a `lookup_interned_symbol ()' right before, I'd rather change users so that they lock before `lookup' and unlock after `intern': lock (&symbols_mutex); sym = lookup_interned_symbol (name); if (scm_is_false (sym)) { sym = scm_i_c_make_symbol (...); intern_symbol (sym); } unlock (&symbols_mutex); Is it doable? Thanks, Ludo'.