[Vm-dev] VM Maker: VMMaker.oscog-eem.2060.mcz

[Levente Uzonyi]

Hi Eliot,

On Sat, 31 Dec 2016, Eliot Miranda wrote:

> I think one uses exactly the strategy you used in the Smalltalk code, namely:
>    if the structure needs growing, create a grown initialised copy, and then do a test-and-set to update the pointer.

That way you would miss the updates of existing semaphores during the 
copy.
And this is what I think a global counter could prevent. Increment the 
counter on each semaphore update. If its value has changed during 
copying, then the copy will have to be repeated.

> Well, I think pinning should help with a number of things.  But I don't see how it suffices here.  Making signal thread-safe is probably quite difficult, so the indirect request signal/grant signal scheme
> ,that the external semaphore table provides is convenient.  What am I missing?

If the Semaphores were pinned, then their address could be used direcly 
from the plugin code to signal them. So, I think we wouldn't need the 
table. Perhaps there's something else this table does I'm not aware of.

Levente