[RFC] [Plugin] Fixes 100% cpu load

[Dr Andrew John Hughes]

On 10:07 Thu 30 Sep     , Andrew Haley wrote:
> On 09/28/2010 10:14 PM, Andrew Su wrote:
> > Update:
> > -Changed to use ConcurrentHashMap.
> > -Used suggestion of putIfAbsent instead of locking.
> > 
> > Cheers,
> > --Andrew
> > 
> > Attached:
> > Modified version of file.
> > Patch file.
> 
> One small thing: appLock is a collection of locks, so should be called
> appLocks.
> 

Good point.

> The code
> 
>   appLock.get(identifier).notifyAll();
> 
> is weird: isn't that lock already held?
> 

Well, notifyAll requires that the calling thread holds the monitor so
calling it outside an appLock.get(identifier) synchronised block would
throw an IllegalMonitorStateException.

The real problem (and what I think you may actually be referring to) is
that the wait() call is never going to be made, because if an init message
is being processed, the lock is already held and another thread won't be
able to enter the else block.  I don't see anywhere in the init processing
where the lock is released.

> The way locking is being done here makes me very nervous.  The locked
> region is very long, and the interaction between threads and locks is
> complex.
> 
> I wonder if the additional synchronization is patching around a design
> problem.
> 

Agreed.  I've already gone over this twice and still managed to miss the
whole wait/notifyAll part.  This is why I'd like to see some more information
on the general architecture we're dealing with.

If it's the case that each message needs to be processed sequentially, then
the simplest solution may be to allocate a thread per identifier and give it
a work queue of messages which are then processed one at a time, in order.
But this may be complete nonsense, as I don't know what the overall design is.

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8