Subj : Re: What is the real costs of LOCK on x86 multiprocesor machine?
To   : comp.programming.threads
From : chris noonan
Date : Sun Jul 31 2005 06:24 am


Joe Seigh wrote:
> chris noonan wrote:
> > 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.
> >[snip]
>
> 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.

The LOCK prefixes are always in the source code,
unconditionally. So the software ships with LOCK in
the binaries. The software installer determines
whether the machine is uniprocessor or multiprocessor.
If the former, it alters the binary file accordingly,
overwriting the LOCK prefixes with NOP, working from
a list of offsets that is potentially different for
each compilation.

Is that what you were asking?

Chris

.