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