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

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

Hi,

Now we introduce critical sections to make some state transitions atomic.

Not long ago, I said that any LeaveCS + Wait + Re-EnterCS is
bogus.  I still believe this is true, but here is a subtle difference:

+		LeaveCriticalSection(&wmm->cs);
+		WaitForSingleObject(wmm->hThread, INFINITE);
+		EnterCriticalSection(&wmm->cs);
+		/* anything may happen while waiting, so restart */
+		continue; /* restart_transation */

The key is the continue statement and the concept of transactions that
either complete or are aborted in sane state.  If you don't want to
abort with an error, then you have to try and restart the transaction.

You'll notice that it does not protect against wmm being freed while
waiting.  Indeed the code doesn't protect itself against one thread
calling Close while another thread is calling another command!
Though you can safely call Close while music plays.

Actually, I don't know how to protect against calling Close while
another call is in effect.  The other might just be entering my
DriverProc, before my driver can InterLockIncrement some nesting
counter.  Nah, only winmm has a chance to control that.

Defining the scope of the transaction is not trivial.

Another limit: My "start player" transaction comprises thread
creation, but not setting the From&To parameters.  It cannot contain
MCI_WAIT either, that would dead-lock.  Thus when 2 players start
concurrently, the winning player may end up playing mixed From&To
bounds and the loser may find itself waiting for the winner to finish,
despite its original player thread having been aborted.

Well, I've yet to see an app start 2 players concurrently in the MS
world where most apps are still single-threaded event loop dispatchers.

I don't know how native behaves in such a situation.  Another possibility
would have been to let one player return with NONAPPLICABLE_FUNCTION.

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0010-mciseq-Limit-concurrency-when-starting-to-play.patch
Type: application/octet-stream
Size: 3975 bytes
Desc: 0010-mciseq-Limit-concurrency-when-starting-to-play.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20121004/79085936/attachment.obj>