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 <m...@netris.org> 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 > >
