[gambit-list] Memory ordering considerations in Gambit SMP?

Marc Feeley feeley at iro.umontreal.ca
Mon Nov 13 21:08:53 EST 2017


I don’t know what the correct semantics is.  Should Gambit Scheme be considered a high-level language where such details are abstracted, or a low-level language where the programmer has to deal with such issues?  Please cast your vote now!

Marc



> On Nov 13, 2017, at 11:00 AM, Adam <adam.mlmb at gmail.com> wrote:
> 
> Say two Gambit threads that execute concurrently in two different OS threads, are communicating by mutating a structure. E.g.
> 
> Global:
> 
> (define itc-state:set? #f)
> (define itc-state:message #f)
> 
> 
> Thread 1 does:
> (set! itc-state:message ..something..)
> (set! itc-state:set? #t)
> 
> 
> And thread 2 polls:
> (do loop ()
> 
> (if itc-state:set? (act-on! itc-state:message))
> 
> (loop))
> 
> 
> Is any direct polling of structures between OS threads illegal in SMP Gambit, or what is the intended way for this to be coherent?
> 
> 
> (If this was ordinary C code, on a weakly ordered architecture, the worry would be that the |itc-state:set?| update would reach the other CPU core before the |itc-state:message| update reached it and that the program hence would enter into an undefined state - and for this reason programs do a write barrier between.)
> 
> 
> 
> 
> 
> 2017-11-13 21:44 GMT+08:00 Marc Feeley <feeley at iro.umontreal.ca>:
> 
> > On Nov 11, 2017, at 5:13 PM, Adam <adam.mlmb at gmail.com> wrote:
> >
> > Dear Marc,
> >
> > Are there any constraints on what underlying hardware platform SMP Gambit can work on, e.g. architectures with strong memory ordering (AMD64) versus architectures with weak memory ordering (ARM64)?
> 
> No foreseen constraints.
> 
> >
> > Does Gambit export any memory barrier primitive?
> 
> No
> 
> >
> > Do any particular Gambit primitives imply a memory barrier, so these are abstracted away from the user?
> 
> mutex-lock! and there might be others…
> 
> >
> > E.g. (thread-send! t (list 1 2 3)) would imply a memory barrier on weakly ordered systems, if t is being executed on another OS thread, so that when the message is received on the other side, Gambit has automatically ensured that the structure is actually accessible on the receiving end?
> 
> This should work.  If it doesn’t please submit an issue report.
> 
> Marc
> 
> >
> > (https://en.wikipedia.org/wiki/Memory_ordering#Runtime_memory_ordering)
> >
> > Will appreciate a lot to understand how to manage this.
> >
> > Thanks!
> > Adam
> 
> 




More information about the Gambit-list mailing list