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