<AWT Dev> Question regarding locking in EventQueue

[Roman Kennke]

Interesting, I didn't know that. Do you have any pointers to documents
about this? Would be interesting for me to see how that works.
Intuitively I would have assumed that the bytecode level locking would
be more efficient than method calls. I know these are intrinsics, but
still ... how can those be *more* efficient? Just curious...

/Roman

Am Dienstag, den 16.11.2010, 14:01 +0300 schrieb Artem Ananiev:
> Hi, Roman,
> 
> the only reason why ReentrantLock was used is that java.util.concurrent 
> locks are considered slightly more efficient than regular Java monitors. 
> I didn't perform any measurements for this particular change in 
> EventQueue, though, it's just based on my past experience.
> 
> Thanks,
> 
> Artem
> 
> On 11/16/2010 1:56 PM, Roman Kennke wrote:
> > I was just looking at how locking has changed in OpenJDK7 (because I
> > have problems with deadlocks in JDK6), and see that it now uses one
> > global (i.e. appctx local) lock to protect EQ internal structures, as
> > opposed to locking on single EQ objects as was done before. So far so
> > good, this will most likely solve my deadlock problems.
> >
> > I was just wondering why is ReentrantLock used instead of simply using
> > the Java language synchronized construct? The way the locks are used, it
> > seems to be clearer, more straightforward and less error-prone to use
> > the language constructs rather than concurrent API. Is there a specific
> > reason for that?
> >
> > Kind regards, Roman
> >
>