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@iro.umontreal.ca>:

> On Nov 11, 2017, at 5:13 PM, Adam <adam.mlmb@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