Joerg-Cyril.Hoehle@t-systems.com writes:
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).
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.