[PATCH 20/25] mciseq: Check stop condition after sleeping. (Try 5)

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Stop and Pause events will most often occur while the player is sleeping, not running.
Instead of playing a final note before aborting at the top of the loop, check the conditions when waking up.

This time, wmm->dwStatus is accessed using volatile.
+	status = (volatile DWORD) wmm->dwStatus;

After reading through comp.programming.threads, I came to the conclusion that:

1. a HW memory barrier is not needed because:
 + c.p.t' practical argument that given all sorts of system activity, the memory's value
    will eventually find its way to the cache of the processor running the player.
 + as mentioned, the player can deal with a not up to date value and
 + the player loop contains a couple of memory barriers already
    (WaitFor* and other external calls) as part of the player loop.

2. a compiler memory barrier is required.

3. volatile yields a compiler memory barrier that is more portable than
    __asm__ __volatile__ ("":::"memory"); /* gcc/llvm only? */
for as long as Wine's includes do not define one
and until the C1X standard emerges and gives us relaxed atomic reads.


Please note that the patch queue failed to detect some superseded patches:

90588: I should not have named that 17/25 in the first place.
90672 + 90674: the original 20-21/25 were never marked superseded by later patches.
90841+ 90482: try 3 was superseded by try 4, now superseded by this try 5.

Regards,
        Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mciseq-Check-stop-condition-after-sleeping.patch
Type: application/octet-stream
Size: 2840 bytes
Desc: 0001-mciseq-Check-stop-condition-after-sleeping.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20121017/ab54f8c0/attachment.obj>