db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Releasing latches when waiting for locks. When and why?
Date Mon, 20 Nov 2006 21:36:20 GMT
Anders Morken <andersmo@stud.ntnu.no> writes:

> We've taken some long hard looks at the lock manager, and we're
> convinced that there's a lot of potential for improvement in Derby lock
> management. Not that there's anything wrong with the approach taken in
> the current implementation - correctness first, optimization later. =)
> One of the things that we've observed is that on a single-row update
> transaction, a shared lock is obtained on a row in the B-tree container
> just before an exclusive lock is obtained on a row in the data
> container. Off the top of my head I can't remember if why figured out
> exactly why. =)
>> Having said that it would be interesting if someone had time to 
>> implement a higher performance latch implementation and plug it in
>> and see how much it helps.  It would decrease the total time spent
>> in lock manager.

I think Knut Anders has been playing with that idea, so if you're not
doing it yourself I'm sure he (we) would love to hear about any ideas
you may have.

> We've actually considered doing that for fun, but as our goal right now
> is to produce a big honkin' report, not fix anything, we haven't. Still,
> it would probably give a quite significant benefit. 

Reports are a fact of life :)

> Using a Java profiler on a reasonably modern X86 system we've found that
> while acquiring a Derby lock takes about 60-70 microseconds and a latch
> costs 50-60 microseconds in the non-contended (single thread) cases,
> acquiring and releasing a ReentrantLock available in Java 1.5 and up
> costs about 1,5 microseconds. A latch could in theory be about as cheap
> as a ReentrantLock, and on Java 1.5 and up it would make sense to base
> Latches on ReentrantLocks.

Interesting observation! But unfortunately not available for Derby for a long
time :(

> However, just separating the latch data structures from the lock data
> structures could give significant scalability benefits, as right now the
> latches and locks are all stored in the same hash tables, causing
> significant monitor contention in multithreaded cases.

Absolutely. In the multi-core world it is essential to keep the amount
of shared data at an absolute minimum
> I dunno if our report would be of any interest to you guys, but it's not
> finished yet, and I'm not sure if it appropriate to post it just yet.
> Still, it's interesting stuff we're digging up, and it's interesting to
> see how you guys investigate this. =)

I'd love to read it, and I expect others in the Derby community would


View raw message