Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Mon Aug 29 2005 02:26 pm

Alexander Terekhov wrote:
> Joe Seigh wrote:
> 
>>Sean Kelly wrote:
>>
>>>Joe Seigh wrote:
>>
>>Any of the serializing instructions, e.g. cpuid, lock, etc....  Linux
>>uses a dummy XCHG agains the stack (implied LOCK).  The xFENCE are offered
>>as being more efficient since all they basically do is serialize and not
>>do something else as well.             ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> Serialize what? (cpuid aside for a moment.) Chapter and verse please.

"7.4. SERIALIZING INSTRUCTIONS
The IA-32 architecture defines several serializing instructions. These instructions force the
processor to complete all modifications to flags, registers, and memory by previous instructions
and to drain all buffered writes to memory before the next instruction is fetched and executed.
....
The following instructions are serializing instructions:
• Privileged serializing instructions—MOV (to control register),MOV (to debug register),
  WRMSR, INVD, INVLPG, WBINVD, LGDT, LLDT, LIDT, and LTR.
• Non-privileged serializing instructions—CPUID, IRET, and RSM.
• Non-privileged memory ordering instructions—SFENCE, LFENCE, and MFENCE."

LOCK isn't serializing apparently, just ordering but I think there's an
unresolved issue with fetches moving accross LOCK.

> 
> Please show some pseudo code with *FENCE that you think is needed to
> ensure visibility of data published by A in X to C after republishing 
> it in Y by B.

I already proved processor consistency doesn't work the way you think
it does.   QED.  



-- 
Joe Seigh

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

.