<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 5:25 AM, E. Groenenberg <span dir="ltr"><<a href="mailto:quapla@xs4all.nl" target="_blank">quapla@xs4all.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2kp" class="" style="overflow:hidden">Some form of messaging or synchronization would indeed be required,<br>
this could be done f.e. using msg calls (or equivalents), or<br>
use a dedicated small area in the shared memory segment for locking,<br>
using atomic locking instruction (i.e. xchgb instruction for x86 based<br>
processors or ldstub on sparc based processors)</div></blockquote></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Ed,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Exactly - its more than just the shared address space, you need messaging, sequencing, sync etc. - this is why I was suggesting that instead of reinventing an API for simh, using one  that has already been worked and agree upon by the HPC community.  Since HPC is all about performance, I would have a solid belief that not only will the primitives work, but they will offer some of the highest efficiency for the code.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">At the risk of sounds like a fan-boy for OpenSHMEM, it seems to me to be the best of the PGAS family (particularly since it's a library not a new language like Chapel or UPC).   I would be surprised if it did not have all of the things that Bob desired/needs built-in.  In fact, one of the recent additions to OpenSHMEM is the new "counting puts" API which is a distributed (and scalable) locking and synchronization scheme similar to the old eventcount scheme of Reed & Kanodia for UP systems [<a href="http://dl.acm.org/citation.cfm?id=359076">http://dl.acm.org/citation.cfm?id=359076</a>].     The implementations of these primitives map well to the instructions level that you point out. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">That said, if you stay with strict POSIX API instead, I suspect between their shared memory and locking/semaphore primitives, you will be pretty close and i think you should get a solid level of portability.  My two concerns that that strategy are how many of the OSs have actually implemented the POSIX primitives, and when they have, how good a job was done implementing them.   Not that the HPC community is perfect, but they tend to have an incentive to get the performance aspect right.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Clem</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><br></div></div>