[Vm-dev] VM Maker: VMMaker.oscog-eem.2060.mcz
Levente Uzonyi
leves at caesar.elte.hu
Sun Jan 1 14:41:59 UTC 2017
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
More information about the Vm-dev
mailing list