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