From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Thread-unsafe initialization problems in Guile Date: Tue, 5 Mar 2013 15:00:46 -0500 Message-ID: References: <87wqx4w878.fsf@tines.lan> <87vcco5g4j.fsf@gnu.org> <87mwy0vxog.fsf@tines.lan> <877gn62thq.fsf@pobox.com> <87txq7okkj.fsf@tines.lan> <87pq0voiym.fsf@tines.lan> <87mwuow3jx.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8fb1ec48217aff04d732efc9 X-Trace: ger.gmane.org 1362513677 6945 80.91.229.3 (5 Mar 2013 20:01:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Mar 2013 20:01:17 +0000 (UTC) Cc: Andy Wingo , =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 05 21:01:41 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UCy3P-0001pp-3S for guile-devel@m.gmane.org; Tue, 05 Mar 2013 21:01:39 +0100 Original-Received: from localhost ([::1]:56584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCy33-0003wZ-Hk for guile-devel@m.gmane.org; Tue, 05 Mar 2013 15:01:17 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCy2w-0003vD-3s for guile-devel@gnu.org; Tue, 05 Mar 2013 15:01:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCy2u-0008Lg-Nw for guile-devel@gnu.org; Tue, 05 Mar 2013 15:01:10 -0500 Original-Received: from mail-pb0-f45.google.com ([209.85.160.45]:55158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCy2u-0008La-HB; Tue, 05 Mar 2013 15:01:08 -0500 Original-Received: by mail-pb0-f45.google.com with SMTP id ro8so4913528pbb.18 for ; Tue, 05 Mar 2013 12:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=myPaPiwKftAnN3iJ06SLrDNqX67GVG4YH7VaN7D7LDc=; b=LazrhC6+5Eq/uTZv0/kkokT9dOBvXxB/9qcq7qW2aRhF3fdjGH27aSTYRnhKM7V8h+ iXPuBWNwJ8+07h+CFQjVZwBZL7V+TX9gDLriET2aeGT5rstwEOs63TH/zXQN/4bT9+4S lExe95ok4IM78mRrj0ihff0K6EDj7Rux/5PTQdPnjZV4N/XiwRK0+ipjSWL4+nqq0ok3 aq/RTZ21HS5ENFo1n6AsXyYr5RtU9lP5stUEzQISh1Fn4kVKrHGw8l3atN8K8xrO7YfE 47wJyG7NpiH/YFDKzRmIGyuCrMTuNhthE/mq/Vj4JV/MumHifCgsVd+xJ4vBulvNxErm vhHg== X-Received: by 10.68.127.202 with SMTP id ni10mr39547487pbb.124.1362513667079; Tue, 05 Mar 2013 12:01:07 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Tue, 5 Mar 2013 12:00:46 -0800 (PST) In-Reply-To: <87mwuow3jx.fsf@tines.lan> X-Google-Sender-Auth: 85UmSXXYrRINmqFZiEfuABSv9JA X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.45 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:15863 Archived-At: --e89a8fb1ec48217aff04d732efc9 Content-Type: text/plain; charset=ISO-8859-1 I've only read the most recent article you posted, but if I understand correctly, there is a third option: (3) somehow find a way to generate a portable memory barrier instruction. Is that currently possible? I'm not sure that it is. Probably option (2) is best if we can do it. Noah On Thu, Feb 28, 2013 at 4:07 PM, Mark H Weaver wrote: > Here's an article from a reputable source that backs up my claim that > the lazy-initialization pattern that we use in a few places is not > thread-safe: > > http://www.ibm.com/developerworks/java/library/j-dcl/index.html > > Here are the thread-unsafe lazy initializations that I'm aware of: > > ./posix.c:1375: make_rw_port = scm_c_private_variable ("ice-9 > popen", > ./debug.c:217: local_eval_var = scm_c_public_variable ("ice-9 > local-eval", "local-eval"); > ./strports.c:541: eval_string = scm_c_public_lookup ("ice-9 > eval-string", "eval-string"); > > In each of these cases, we have two options: (1) synchronize on every > access of the lazily-initialized variable (including reads), or (2) > abandon lazy initialization. > > Thoughts? > Mark > > --e89a8fb1ec48217aff04d732efc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've only read the most recent article you posted= , but if I understand correctly, there is a third option: (3) somehow find = a way to generate a portable memory barrier instruction. Is that currently = possible? I'm not sure that it is. Probably option (2) is best if we ca= n do it.

Noah


On Thu, Feb 28, 2013 at 4:07 PM, Mark H Weaver <mhw@netris= .org> wrote:
Here's an article from a reputable sourc= e that backs up my claim that
the lazy-initialization pattern that we use in a few places is not
thread-safe:

=A0 http://www.ibm.com/developerworks/java/library/j-dcl= /index.html

Here are the thread-unsafe lazy initializations that I'm aware of:

./posix.c:1375: =A0 =A0 =A0 =A0 =A0 =A0make_rw_port =3D scm_c_private_varia= ble ("ice-9 popen",
./debug.c:217: =A0 =A0local_eval_var =3D scm_c_public_variable ("ice-9= local-eval", "local-eval");
./strports.c:541: =A0 =A0 =A0eval_string =3D scm_c_public_lookup ("ice= -9 eval-string", "eval-string");

In each of these cases, we have two options: (1) synchronize on every=
access of the lazily-initialized variable (including reads), or (2)
abandon lazy initialization.

=A0 Thoughts?
=A0 =A0 Mark


--e89a8fb1ec48217aff04d732efc9--