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

[Michael Stefaniuc]

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
http://gcc.gnu.org/ml/gcc/2010-05/msg00116.html
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.


bye
	michael