[PATCH 10/25] mciseq: Limit concurrency when starting to play.

Michael Stefaniuc mstefani at redhat.com
Wed Oct 10 04:56:42 CDT 2012

On 10/10/2012 10:42 AM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> Hi,
> David Laight wrote:
>> Better to code as:
>>        status = wmm->dwStatus;
>>        if (...)
> Incidentally, that's what I did tonight in patch 20/25 try 2.
>> but even then I think the compiler is allowed to perform extra reads.
>> It might, for example, do so if the condition was complicayted and
>> there was a lot of pressure on registers - so instead of spilling 'status'
>> to stack, it would re-read it.
> Interesting. Do you think/believe or are you sure?
With gcc at -O0 'status' will get a stack slot
With optimization turned on probably not as it is just a reference to an
other memory location which can be easily optimized away.

>> With gcc you can force it to only to one read by adding:
>>        asm volatile("":::"memory");
>> The only portable way is with volatile.
> "only portable way" from the C perspective. However, given a specific target
> environment, we could use its API functions.
> Either
> MemoryBarrier(); /* which MSDN documents but Wine does not provide in include/*.h
> Or
> InterlockedExchange(&status, wmm->dwStatus);
> So if AJ is still not satisfied with try 2, I'll change all reads of wmm->dwStatus
> within the player into InterlockedExchange.
> Yet I think that would be a superfluous extra memory barrier within the player.


More information about the wine-devel mailing list