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

Adam adam.mlmb at gmail.com
Mon Nov 13 11:00:04 EST 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20171114/7bc23e41/attachment.htm>


More information about the Gambit-list mailing list