On Tue, 10 May 2016 16:30:30 +0200 Andy Wingo <wi...@pobox.com> wrote: > I think we have no plans for giving up pthreads. The problem is that > like you say, if there is no shared state, and your architecture has a > reasonable memory model (Intel's memory model is really great to > program), then you're fine. But if you don't have a good mental model > on what is shared state, or your architecture doesn't serialize loads > and stores... well there things are likely to break.
Hi Andy, That I wasn't expecting. So you are saying that some parts of guile rely on the ordering guarantees of the x86 memory model (or something like it) with respect to atomic operations on some internal localised shared state[1]? Of course, if guile is unduly economical with its synchronisation on atomics, that doesn't stop the compiler doing some reordering for you, particularly now there is a C11 memory model. Looking at the pthread related stuff in libguile, it seems to be written by someone/people who know what they are doing. Are you referring specifically to the guile VM, and if so is guile-2.2 likely to be more problematic than guile-2.0? Chris [1] I am not talking about things like the loading of guile modules here, which involves global shared state and probably can't be done lock free (and doesn't need to be) and may require other higher level synchronisation such as mutexes.
