dsound: Make sure we're holding the lock on Drop And Stop , try 2

[Maarten Lankhorst]

Peter Beutner schreef:
> But this only works if DSOUND_Stop and DSOUND_Release are called from
> different threads, right?
It is during shutdown, DSOUND has an internal timer/thread called the
mixer, it calls DSOUND_Stop because we signalled it to stop playbacking,
then the program calls idirectsoundbuffer_release which calls
DSOUND_Release. Since DSOUND_release also unsets hwbuf, the timer would
then continue to use an uninitialized waveout interface, which could
result in something even uglier.
> Isn't the real problem that when ALSA_DestroyRingMessage(*) is called from
> IDsDriverBuffer_Release it doesn't check if there are still any "fast
> messages"
> in the queue which wait for their message to be handled?
> Just from a quick look it seems you could theoretically trigger the
> same deadlock with the WODM_RESET & WODM_CLOSE messages when using
> the waveout system.
I agree it's horribly complex, I hope to improve that in alsa during
summer. However when calling IDsDriverbuffer_Release dsound says it no
longer has anything that uses that interface. Because
IDsDriverBuffer_Stop hasn't returned yet this is in fact untrue: it is
still using idsdriverbuffer, so to make sure it isn't, dsound has to
hold the mixer lock so it waits until the mixer is done playing around.

You are _NOT_ allowed to call Release on a interface if you still have
something that uses the interface. The bug is definitely in dsound, it
just resulted in winealsa being unresponsive.

Maarten