[RFC][plugin]: fix fixme

[Denis Lila]

> Ok, where are the other uses? Just in that class?

Yes.

> How do you come to this conclusion? puts aren't atomic.

I know; hence what I wrote next:

> Thinking
> about it more, I realize that was a mistake: if an
> object is being removed from the hash map at the same
> time as a get is executing, and if the two objects in
> question happen to be in the same bucket, that would be
> very bad.


> > The simplest way to fix this would be to synchronize
> > everything, but reads seem to be pretty common, so that
> > might be bad.
> >
> > The attached patch uses ConcurrentHashMaps.
> >
> 
> Are you sure you understand how these work?
> 
> reads aren't blocked and you're not using any of the atomic
> operations.
> I really need to look at the whole usage of these maps to see the best
> route forward.

Reads don't need to block. Deepak, please correct me if I'm
wrong on this, but reads of object x from the store can't race
with store.reference(x) calls.

And even if they could, we wouldn't gain anything by making reads
block (and we'd lose performance).

For example, consider a call to store.getIdentifier(X) and suppose
it's racing with a call to store.reference(X).
getIdentifier has no side effects and exactly 2 possible returns:
return 0 if it can't find its argument, and the argument's id otherwise. 

Now, if the read and the write are racing and the read is synchronized,
the choice as to who goes first is undefined, so we have 2 possible
outcomes:

(1) The JVM decides the getIdentifier(X) goes first. It returns 0.
(2) The JVM decides the reference(X) goes first. getIdentifier(X) goes
second, and it returns X's id.
So, in the HashMaps + blocking reads implementation,
both return values are possible, and which one is returned is undefined.

Now suppose I use ConcurrentHashMaps and getIdentifier is _not_
synchronized. getIdentifier(X) and reference(X) will be executing
concurrently, and the return value of getIdentifier(X) will be 0
if the identifiers.put(X, next) call in reference(X) has not
completed and it will be X's id if it has completed (according
to the CHM spec). Whether put(X, next) will complete before
getIdentifier(X) is still undefined.
So, in the ConcurrentHashMaps + non-blocking reads implementation,
both return values are possible, and which one is returned is undefined.

The two implementations are effectively exactly the same.
Or am I missing something?

Regards,
Denis.

----- Original Message -----
> On 16:58 Wed 30 Mar , Denis Lila wrote:
> > > Are these the only use of objects, counts and identifiers? If so,
> > > this
> > > looks ok.
> >
> > They're not the only uses. They're the only writes.
> 
> 
...snip...