November 2012 - Wine-Devel - list.winehq.org

WANTED: compiler barrier for use within Wine

by Joerg-Cyril.Hoehle＠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

Nov. 1, 2012

Re: WANTED: compiler barrier for use within Wine

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)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(a)winehq.org

Nov. 1, 2012

WANTED: compiler barrier for use within Wine

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I'm missing a portable compiler barrier for use within Wine. MSVC has _ReadBarrier, _ReadWriteBarrier etc. http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.80).aspx GCC has __asm__ __volatile__("":::"memory"); However compilers other than GCC may be used to compile Wine, e.g. I believe some people use LLVM (I've heard that LLVM parses GCC asm statements, but what #ifdef would be appropriate?). Is __asm__ __volatile__("":::"memory"); portable across all targets that Wine supports? Without that, it seems to me that using DWORD foo = (volatile DWORD) bar; is the most "portable" way of achieving a compiler barrier within the scope of Wine, even though the pthreads gurus will spit at it. At least, every C compiler parses volatile, unlike __asm__... Background: I want an atomic read of whatever value a single aligned int (or DOWRD or whatever) currently appears visible to one core. - Critical sections and mutexes are out of question, because they both can block. - InterlockedXyExchange are not appropriate, because there's nothing to exchange. Furthermore, they introduce a full hardware memory barrier whereas a compiler barrier suffices. All I want is something like memory_order_consume from the C++11 standard. 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). What do you think? Jörg Höhle

Nov. 1, 2012