BROOKLYN-245: improve synchronization in entity

[aledsage]

No description provided.

[ahgittin]

the BasicSubscriptionSupport.getSubscriptionTracker() method this calls also synchronizes on AbstractEntity.this (line 1494 in new money) -- so no impact whether this method is synchronized or not

in contrast to the change to unsynchronize getSubscriptionContext() here, synchronizing on something when getting the tracker looks right as it is setting a local field. however the underlying method (line 1498 new money) calls to getSubscriptionContext() while synchronized on this so i think we haven't entirely eliminated the deadlock prospect.

feels like line 1498 could double-check the tracker, and load the getSubscriptionContext() between the checks eg

if (tracker!=null) return tracker;
subs = getSubscriptionContext();
synchronized (AbstractEntity.this) {
    if (tracker!=null) return tracker;
    tracker = new Tracker(subs);
    return tracker;
}

[aledsage]

I think this existing code is ok, in terms of the deadlock encountered in BROOKLYN-245. The AttributeMap should never call into getSubscriptionTracker(), so there will never be a call to it while holding a lock on AttributeMap.values.

In terms of calling getSubscriptionContext() while holding other locks (e.g. on AbstractEntity.this) we should be ok: it will synchronize on EntityManagementSupport.this and will then call into the management context's subscription manager, but that code should never call out to alien code.

It would be good to remove the synchronized (AbstractEntity.this) entirely, to have simpler concurrency code. But we must be aware that the caller might already have synchronized on the entity instance when calling subscribe(). So removing this synchronization doesn't eliminate any deadlocks - instead we must be sure that synchronizing on the entity instance won't risk deadlocks.

As an aside, note that double-checked locking is broken if the field is not declared volatile.

Given that, are you ok leaving the code as-is in this PR?

[aledsage]

I've added another commit that does the getSubscriptionContext() call outside of the synchronized block - just in case there are any problems I haven't thought of there!

I didn't bother with double-checked locking and volatile field. If we care hugely about performance here, then we should instantiate it on entity initialisation (before this method is called), and get rid of all the synchronization in the method. That would be a simpler concurrency model. But it's a bit fiddly because of the use EntityManagementSupport (and its lazy initialisation, and use of NonDeploymentManagementContext on construction).

[ahgittin]

one comment to address

[ahgittin]

i've merged this, with one further small tidy-up 9720743

this and #97 have been backported to 0.9.0