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

Peter Beutner p.beutner at gmx.net
Sat Apr 21 08:44:30 CDT 2007

Maarten Lankhorst schrieb:
> This fixes an interesting deadlock with the alsa driver:
> DSOUND_Stop is called, message is added to thread queue.
> DSOUND_Release is called, message is added to thread queue.
> Both are fast messages, so second is added before first.

But this only works if DSOUND_Stop and DSOUND_Release are called
from different threads, right?

> thread reads: We're going down! And terminates.
> DSOUND_Stop's message is never read and it waits till eternity, so
> starting/stopping never occurs any more.

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.

(*) probably affects all other sound drivers as well which use this
(horrible complex) message ring buffer system.

More information about the wine-devel mailing list