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

[Eliot Miranda]

Hi Levente,

> On Jan 1, 2017, at 6:41 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
> 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.

Makes sense.

>> 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.

The signal primitive is not thread-safe; it can only be invoked at a suspension point.  The external semaphore table safely asynchronously requests signals which are later performed by the vm at a safe point (the checkInterrupts routine).

> Levente