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