Re: Thread-unsafe initialization problems in Guile

[Noah Lavine]

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 <address@hidden> 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