WANTED: compiler barrier for use within Wine

Hi,

I'm missing a portable compiler barrier for use within Wine.

MSVC has _ReadBarrier, _ReadWriteBarrier etc.
http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.80).aspx

GCC has __asm__ __volatile__("":::"memory");

However compilers other than GCC may be used to compile Wine, e.g.
I believe some people use LLVM (I've heard that LLVM parses GCC
asm statements, but what #ifdef would be appropriate?).

Is __asm__ __volatile__("":::"memory");
portable across all targets that Wine supports?

Without that, it seems to me that using
DWORD foo = (volatile DWORD) bar;
is the most "portable" way of achieving a compiler barrier
within the scope of Wine,
even though the pthreads gurus will spit at it.

At least, every C compiler parses volatile, unlike __asm__...

Background: I want an atomic read of whatever value a single aligned
int (or DOWRD or whatever) currently appears visible to one core.
- Critical sections and mutexes are out of question, because they
  both can block.
- InterlockedXyExchange are not appropriate, because there's nothing
  to exchange.  Furthermore, they introduce a full hardware memory barrier
  whereas a compiler barrier suffices.

All I want is something like memory_order_consume from the C++11 standard.

Alexandre Julliard wrote:
> > - I don't want the player to block in a CS.  All it needs is to poll dwStatus.
>
> It wouldn't block if you don't do other things inside the CS.

I don't understand that one.  Code in the player like:
    EnterCS(wmm->lock);
    local = wmm->dwStatus;
    LeaveCS(wmm->lock);
*will* block when the app calls API functions that take the lock, even if
for a short time.  For instance, an app bombarding mmdevapi with GetCurrentPadding
requests will disturb the periodic feeder in winealsa.drv:alsa_push_buffer_data.
When that happens, only the UNIX scheduler knows when that thread will get
scheduled again (even worse, it must first schedule the Wine server).

What do you think?
    Jörg Höhle