WANTED: compiler barrier for use within Wine

[Joerg-Cyril.Hoehle at t-systems.com]

Alexandre Julliard wrote:
>A critical section doesn't involve the wine server.
I simply saw that path:
RtlEnterCriticalSection -> RtlpWaitForCriticalSection -> -> wait_semaphore
 -> fast_wait
  | NTDLL_wait_for_multiple_objects -> SERVER_START_REQ
but I don't like to argue about your server with you.

It doesn't bug me at all whether a blocked CS needs help from
the Wine server or whether a Linux futex suffices.  I simply want to
avoid a CS where it is strictly superfluous.

>I also fail to see why something like GetCurrentPadding would need to
>change the status.
Sorry for introducing that example from another Wine dll.  It
caused confusion.  mmdevapi:GCP is unrelated to mcimidi:wmm->dwStatus

>Obviously if you have a global critical section protecting everything
>that may be an issue, but you can fix that.
Indeed, winealsa could use 2 CS: one for preventing application-level
concurrency, the other for controlling the internal periodic feeder.

However rather than augmenting the number and uses of CS and thinking
about lock convoys and dead locks, I prefer correct designs with fewer CS.

>I also have a hard time believing that a simple crit section would
>make a difference here, considering how many other sections are
>potentially entered in that player loop.
There aren't.  The loop is:
 - get note (no CS)
 - may Sleep (small wrapper above UNIX sleep)
 - somehow check wmm->dwStatus for STOP
 - midiOutShortMsg (any number of CS, I don't care, the contract of
     this function simply is "get that note out ASAP".)

The only question is: how to read wmm->dwStatus?

Regards,
 Jörg Höhle