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

[Tony Hosking]

Not portably.  Different memory models will behave differently.  For  
safety we need the lock.  But, seriously, how much contention will  
there be?

On 8 Nov 2009, at 19:35, Jay K wrote:

> 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/20091108/18ab284d/attachment-0002.html>