WANTED: compiler barrier for use within Wine

[Alexandre Julliard]

<Joerg-Cyril.Hoehle at t-systems.com> writes:

> Alexandre Julliard wrote:
>>> 2. 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).

A critical section doesn't involve the wine server. I also fail to see
why something like GetCurrentPadding would need to change the
status. Obviously if you have a global critical section protecting
everything that may be an issue, but you can fix that.

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.

I strongly recommend that you stop playing games with the compiler and
start thinking about doing this using the existing synchronization
primitives (either crit section or interlocked functions) in the way
that they are meant to be used. Once you have code that is demonstrably
correct WRT threading, and you can show that the primitives in question
are the cause of trouble, then we can talk about taking shortcuts.

-- 
Alexandre Julliard
julliard at winehq.org