Thin Lock Implementation

[Robert Jacques]

On Fri, 22 Aug 2008 14:08:28 -0400, Leandro Lucarella <llucax at gmail.com>  
wrote:

> Bartosz Milewski, el 20 de agosto a las 15:14 me escribiste:
>> Brad Roberts wrote:
>> >I'll agree that inbetween is relatively rare, but just because there's
>> >contention, doesn't require the switch to heavy locks.  In a lot of  
>> the code I
>> >have written, one spin (assuming the spin utilizes rep; nop;) is  
>> sufficient for
>> >the 'blocked' acquire to finish it's acquire.  The use of heavy weight  
>> locks in
>> >that scenario is a net loss.
>>
>> A thin lock is not a spin lock. It's an optimization on top of the OS  
>> lock
>> specifically for the no-contention case. If there is contention, the OS  
>> lock,
>> which is part of FatLock, is used. It presumably does its own  
>> optimizations, so
>> calling it "heavy weight" may be unfair.
>
> I would love to hear you point on optimizing an OS lock that is already
> optimized.
>
> Is that really necessary? Do you have numbers that back you up?
>
> Thank you.
>
Assuming the OS lock involves a kernel call then yes, there is a major  
performance difference. Kernel calls are the reason that GC programs beat  
programs using malloc and minimizing them is the secret behind all the  
various 'fast' malloc replacements.