[icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true

[Deepak Bhole]

* Denis Lila <dlila at redhat.com> [2011-04-14 17:30]:
> > Denis brought this up too. Maybe I am missing something -- even if CHM
> > does its own locking, wouldn't the caller thread still own the
> > monitor,
> > thus making it a non-issue? We'd just be locking it earlier. If
> > outside
> > locking is a concern, that would make CHM very dangerous to use in any
> > sort of multi-threaded environment that might lock it before an op.
> 
> Whenever an object L does it's own locking, there's a deadlock
> possibility if we have code like this:
> 
> synchronized(L) {
>   synchronized(Other) {
>     code;
>   }
> }
> 
> synchronized(Other) {
>   L.anyMethod();
> }
>

True, so lets say CHM = L, we have:

synchronized(L) {
    L.method()
}

in our code, and then what can CHM have to make this an issue?

synchronized(L) {
    synchronized(anything_else) { ... }
}

?

That would still not be an issue as the caller has already locked L. The
caller (PAV) does no secondary locking.

Sorry if I sound like I am trying to be difficult.. I am just trying to
understand if there really is a problem here and if so, where.

Cheers,
Deepak

> And combing through code trying to find this pattern would be very
> annoying.
> For us, that's not a problem (yet). My concern when I brought this up
> was one of increased contention, but thinking about it more, it
> didn't make much sense, so I won't mention it.
> 
> I really don't think we should go back to HMs though. If we did that
> we'd have to lock on every get.
> 
> Regards,
> Denis.
> 
> ----- Original Message -----
> > * Dr Andrew John Hughes <ahughes at redhat.com> [2011-04-14 16:32]:
> > > On 09:22 Thu 14 Apr , Deepak Bhole wrote:
> > > > * Dr Andrew John Hughes <ahughes at redhat.com> [2011-04-14 07:41]:
> > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote:
> > > > > > * Deepak Bhole <dbhole at redhat.com> [2011-04-13 20:48]:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Andrew mentioned in one of the previous threads that the
> > > > > > > current plugin
> ...