unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: "Andy Wingo" <wingo@pobox.com>, "Ludovic Courtès" <ludo@gnu.org>,
	guile-devel <guile-devel@gnu.org>
Subject: Re: Thread-unsafe initialization problems in Guile
Date: Tue, 05 Mar 2013 22:24:09 -0500	[thread overview]
Message-ID: <8738w9cism.fsf@tines.lan> (raw)
In-Reply-To: <CA+U71=MgFySKNStwg7S1=RnB=+q9hrL1rqJoHO27VMxBytDnRg@mail.gmail.com> (Noah Lavine's message of "Tue, 5 Mar 2013 15:00:46 -0500")

Hi Noah,

I wrote:
>   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.

Noah Lavine <noah.b.lavine@gmail.com> writes:
> 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?

If we were to do that, we'd have to add memory barriers in two places:
(1) after writing to the lazily-initialized variable, and (2) before
reading from it.  While memory barriers are somewhat more efficient than
mutexes, they are still very expensive.

As for portability, C11 is the first C standard to support memory
barriers.  For now, our best bet would probably be to use libatomic_ops,
which is also used by libgc.

> Probably option (2) is best if we can do it.

Agreed.  Unfortunately, in these cases option (2) would significantly
increase the number of modules that need to be loaded at initialization
time.  That's why I reluctantly chose option (1).

     Regards,
       Mark



  reply	other threads:[~2013-03-06  3:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29 18:54 Thread-unsafe initialization problems in Guile Mark H Weaver
2012-11-29 20:05 ` Ludovic Courtès
2012-11-29 22:42   ` Mark H Weaver
2013-01-21 20:04     ` Andy Wingo
2013-01-23 17:50       ` Mark H Weaver
2013-01-23 18:25         ` Mark H Weaver
2013-02-28 21:07           ` Mark H Weaver
2013-02-28 23:20             ` [PATCH] Fix thread-unsafe lazy initializations Mark H Weaver
2013-03-01  9:23               ` Ludovic Courtès
2013-03-05 18:53                 ` Mark H Weaver
2013-03-05 20:45                   ` Ludovic Courtès
2013-03-05 21:10                     ` Mark H Weaver
2013-03-05 20:00             ` Thread-unsafe initialization problems in Guile Noah Lavine
2013-03-06  3:24               ` Mark H Weaver [this message]
2013-03-06  3:39                 ` Noah Lavine
2013-03-06  3:50                   ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8738w9cism.fsf@tines.lan \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=noah.b.lavine@gmail.com \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).