Subj : Re: What is the real costs of LOCK on x86 multiprocesor machine?
To   : comp.programming.threads
From : Joe Seigh
Date : Sat Jul 30 2005 10:05 am

chris noonan wrote:
> Oliver S. wrote:
> 
>>>I stepped through InterlockedIncrement and there definitely IS lock.
>>
>>And there are also locks on Enter- and LeaveCriticalSection.
>>MS dropped the two versions of this functions win kernel32.dll
>>from NT4 to Win2K.
> 
> 
> I vaguely remember encountering the LOCK prefix
> in one or two places in Microsoft OS code disassembly
> (uniprocessor installation). I assumed it was simply
> a mistake, something like new routines being hacked
> in quickly without them taking the trouble to add
> the offsets of the LOCK prefixes to the list to be
> NOP'ed out.
> 
> Most of my work is done with NT4 SP4. If subsequent
> versions retain the LOCK prefix in uniprocessor
> mode that is interesting. Obviously Microsoft got
> a measurable performance boost by removing the LOCKs
> (I do too, in my code) or they wouldn't have taken
> the trouble. By the way, the routines I studied most
> were heap functions: NtAllocateHeap etc.
> 
> 

Statically or dynamically linked code?  The only case I
think you can safely get away with making LOCK optional
is in system dynamically linked libraries that are hardware
configuration specific.  I use LOCK in inlined code since it's
in effect statically linked and you don't know where the code
will eventually execute.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.