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

[Alexandre Julliard]

<Joerg-Cyril.Hoehle at t-systems.com> writes:

> Alexandre Julliard wrote:
>
>>This makes no sense, you can't make assumptions about the generated code
>>from the shape of the if statements.
> Don't || and && impose an evaluation order?

Only if there are side effects.

>> Also there's no such thing as
>>"conceptually volatile", unless you add explicit memory barriers.
> Forget about "conceptually volatile".  I meant to express the idea
> that some variable may be updated from another thread.  This has
> nothing to do with the C keyword of that name.
>
> Once again I read some articles about memory barriers and fail to see
> what's wrong with the final code (after patch 21/25):
>
> 	if (wmm->dwStatus == MCI_MODE_STOP || wmm->dwStatus == MCI_MODE_NOT_READY)
> 	    break;
> 	else if (wmm->dwStatus != MCI_MODE_PLAY || recheck)
> 	    continue;

That depends on what state transitions are possible and what the
behavior should be in various states. I haven't analyzed that in detail.

However, it does *not* depend on how you write the code. Whether you use
one complex if() instead of two simple ones, or a switch(), or any other
way that is logically equivalent. Either it's reliable in all cases, or
in none. Writing complicated if() statements just because you think it
somehow helps with concurrency is misguided.

> 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.

-- 
Alexandre Julliard
julliard at winehq.org