<div dir="ltr">My vote is that Gambit continues to be high level and abstracts the details!</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 9:08 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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!<br>
<br>
Marc<br>
<br>
<br>
<br>
> On Nov 13, 2017, at 11:00 AM, Adam <<a href="mailto:adam.mlmb@gmail.com">adam.mlmb@gmail.com</a>> wrote:<br>
><br>
> Say two Gambit threads that execute concurrently in two different OS threads, are communicating by mutating a structure. E.g.<br>
><br>
> Global:<br>
><br>
> (define itc-state:set? #f)<br>
> (define itc-state:message #f)<br>
><br>
><br>
> Thread 1 does:<br>
> (set! itc-state:message ..something..)<br>
> (set! itc-state:set? #t)<br>
><br>
><br>
> And thread 2 polls:<br>
> (do loop ()<br>
><br>
> (if itc-state:set? (act-on! itc-state:message))<br>
><br>
> (loop))<br>
><br>
><br>
> Is any direct polling of structures between OS threads illegal in SMP Gambit, or what is the intended way for this to be coherent?<br>
><br>
><br>
> (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.)<br>
><br>
><br>
><br>
><br>
><br>
> 2017-11-13 21:44 GMT+08:00 Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>>:<br>
><br>
> > On Nov 11, 2017, at 5:13 PM, Adam <<a href="mailto:adam.mlmb@gmail.com">adam.mlmb@gmail.com</a>> wrote:<br>
> ><br>
> > Dear Marc,<br>
> ><br>
> > 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)?<br>
><br>
> No foreseen constraints.<br>
><br>
> ><br>
> > Does Gambit export any memory barrier primitive?<br>
><br>
> No<br>
><br>
> ><br>
> > Do any particular Gambit primitives imply a memory barrier, so these are abstracted away from the user?<br>
><br>
> mutex-lock! and there might be others…<br>
><br>
> ><br>
> > 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?<br>
><br>
> This should work.  If it doesn’t please submit an issue report.<br>
><br>
> Marc<br>
><br>
> ><br>
> > (<a href="https://en.wikipedia.org/wiki/Memory_ordering#Runtime_memory_ordering" rel="noreferrer" target="_blank">https://en.wikipedia.org/<wbr>wiki/Memory_ordering#Runtime_<wbr>memory_ordering</a>)<br>
> ><br>
> > Will appreciate a lot to understand how to manage this.<br>
> ><br>
> > Thanks!<br>
> > Adam<br>
><br>
><br>
<br>
______________________________<wbr>_________________<br>
Gambit-list mailing list<br>
<a href="mailto:Gambit-list@iro.umontreal.ca">Gambit-list@iro.umontreal.ca</a><br>
<a href="https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list" rel="noreferrer" target="_blank">https://webmail.iro.umontreal.<wbr>ca/mailman/listinfo/gambit-<wbr>list</a><br>
</blockquote></div><br></div>