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 don't see the indexesByObjects dictionary actually being updated, except
in the case of setting a new externalObjectsArray in the ExternalSemaphoreTable.
I think I am overlooking something?

Dave