On Fri, 24 Oct 2014, David T. Lewis wrote:

> On Fri, Oct 24, 2014 at 09:52:11PM +0200, Levente Uzonyi wrote:
>> On Fri, 24 Oct 2014, Bert Freudenberg wrote:
>>
>>> Another thought: is it really necessary to cache the index in the
>>> semaphore? Wouldn't scanning the externalObjectsTable for self be
>>> efficient enough? It's pretty small, after all.
>>
>> That's exactly what the current implementation does (scans the table), and
>> this is what I want to avoid, because it doesn't scale. The table is small
>> when you start your image, but it can easily grow large - especially on a
>> server (3 semaphores per socket) - and it never gets shrinked. So once it
>> grows, it'll stay slow "forever".
>>
>> And no, it's not absolutely necessary to store the index in the
>> semaphores. The new implementation uses an IdentityDictionary to store the
>> indexes of non-semaphores. The same method could work for semaphores too.
>> But it's convenient to store the index in the semaphore, otherwise the
>> method which creates and registers a new semaphore has to return two
>> values - the index and the semaphore - which is cumbersome.
>> It's also faster to ask for a new Semaphore from the
>> ExternalSemaphoreTable, because that way it knows that the
>> Semaphore is not registered.
>
> I also like the implementation overall, but it seems to me that a Semaphore
> should not be responsible for knowing about whether somebody used it in the
> external objects array. It seems more natural for ExternalSemaphoreTable
> to be responsible for keeping track of the relationship between semaphores
> and external resources. Thus I don't really like the #indexInExternalObjectsArray
> instance variable in Semaphore.
>
> On the other hand, in your earlier post introducing this topic, you said:
>
>>  I also thought that I'll create a special semaphore (ExternalSemaphore -
>>  which is a subclass of Semaphore) that knows its own index in the external
>>  objects array.
>
> So IMO, maybe maybe your original concept is better, even if it requires
> another class. An ExternalSemaphore would be a Semaphore that knows about
> its place in the ExternalObjectsArray, but semaphores in general do not
> need to know about that.
>
> I'm not sure which would be better, but it seems to me that either
> ExternalSemaphoreTable should be responsible for maintaining the relationship
> (presumably with an IdentityDictionary), or ExternalSemaphore should be
> a kind of semaphore that knows something more about its place in the world.

The problem with ExternalSemaphore idea is that it requires VM changes. 
The VM is not willing to signal instances of non-Semaphores. AFAIK 
signaling is based on what's in slot 19 of the specialObjectsArray. But 
changing the class there is not possible, because other VM mechanisms also 
rely on the content of that slot.

Levente

>
> Dave
>
>
>