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

[Tony Hosking]

It would be nice to use CAS and friends (load-linked/store- 
conditional) but they are not portable.  It would require target- 
dependencies.

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

> I don't know. I just look at all code overly critically..including  
> for overly coarse grained locking (which includes some vs. none).
> I guess the argument could be that the critical section -- the part  
> of code that executes under the lock -- is very short, so it can't  
> make much of a difference.
>
> Writing the global with an "InterlockedExchange" might be good.
>
> Maybe we should add this as a portably available interface?
> "This" being MemoryBarrier and/or well, er, um, I guess you already  
> did, the IA64 stuff, which is similar to the Win32 stuff.
> I should update the NT/x86 backend for that stuff and then we can  
> move on and use them.
>
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Sun, 8 Nov 2009 19:39:00 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Self() locking slots almost unnecessary -- if  
> only we had "MemoryBarrier".
>
> 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/b69fbae6/attachment-0002.html>