[M3devel] Self() locking slots almost unnecessary -- if only we had "MemoryBarrier".

[Jay K]

Self() doesn't have to lock slots AS LONG AS in AssignSlot:

 

          SUBARRAY (new_slots^, 0, n) := slots^;
          slots := new_slots;

occurs in the order written.

That SUBARRAY() := finishes before slots := runs.

Aggressively compilers/processors need not execute these in the order written.

 

Do we have a way to guarantee that?

 

Something like:

          SUBARRAY (new_slots^, 0, n) := slots^;
>        MemoryBarrier();

          slots := new_slots;


?

 

MemoryBarrier on Windows is implemented as one "special" instruction -- for x86, AMD64, and IA64.

Those implementations are portable to any OS running those architectures.

Though they aren't expressed in a portable form (x86 inline assembly and C compiler intrinsincs).

In particular:

 

winnt.h:

amd64:

#define MemoryBarrier __faststorefence


x86:

FORCEINLINE
VOID
MemoryBarrier (
    VOID
    )
{
    LONG Barrier;
    __asm {
        xchg Barrier, eax
    }
}


ia64:

#define MemoryBarrier           __mf


 

 - Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091109/6a9a13d6/attachment-0001.html>