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

[Denis Lila]

> synchronized(L) {
> L.method()
> }

In my example that was sync(Other) { L.foo(); }

However, I pointed out that we don't have any cases like
that in our code, so strictly speaking, there is no problem (yet).

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

I agree that there's no correctness problem. AFAICS, the reasons for
having separate locks would be
1. To protect against the introduction of future deadlocking code
(that follows the pattern I mentioned).
2. Andrew mentioned that we're not using the present locking for
safe access to the maps - we're just using it for wait/notify,
and it's cleaner to have separate objects for this.

> 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.

I know :-D.

Regards,
Denis.

----- Original Message -----
> * 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:
> 

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

> 
> ?
> 
> 

> 
> 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
> > ...