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