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

Bob Coleman bobcolem at yahoo.com
Mon Nov 13 22:44:39 EST 2017


My vote is that Gambit continues to be high level and abstracts the details!

On Mon, Nov 13, 2017 at 9:08 PM, Marc Feeley <feeley at iro.umontreal.ca>
wrote:

> 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
> >
> >
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20171113/caa0933c/attachment.htm>


More information about the Gambit-list mailing list