转：waveOutReset的N种死法, 及其解决方案-优快云博客

http://hi.baidu.com/zorru/blog/item/fa67d4d8c1d5423d32fa1c06.html

waveOutReset的N种死法, 及其解决方案

2009年06月08日星期一 13:14

我遭遇到了调用waveOutReset死锁的问题，在GOOGLE上一搜，遇到同样问题的人还真不少，但没有人很明确地找到造成DEADLOCK的原因，都是糊里糊涂就把问题解决了，然后把运行OK的代码一贴完事。我花了四五个小时才彻底摸清楚规律，把这经验拿出来共享

原则：
(1) waveOutReset不是立即返回的函数, 而需要等待驻留在WAVEDEV里的音频BUFFER全部标记为WOM_DONE,经过callback proc处理完毕后, waveOutReset才会返回.
(2) 在waveOutReset调用到返回之间的这段时间内, 禁止任何线程对处于reset中的HWAVEOUT调用任何WAVE API, 否则立刻造成死锁.

把握住这两个原则就可以根治waveOutReset死锁问题了. 不过为了把事情描述得更具体些, 我把网上多数人造成死锁的情况列一下, 并给出解决方法

第一种死法:
在回调处理函数WaveCallbackFunc中，对标记为WOM_DONE的BUFFER进行waveOutUnprepareHeader

错误分析:
调用waveOutReset后, 系统内所有未播放的buffer全部被标记为WOM_DONE返回给WaveCallbackFunc, 这属于waveOurReset处理过程的一部分, 此时waveOurReset还未返回. 所以这时如果调用到waveOutUnprepareHeader, 就会立刻造成死锁. 我自己也是犯的这个错误。

解决方法:
在调用waveOurReset之前设置一个FLAG, 然后在WaveCallbackFunc里要调用waveOutUnprepareHeader之前判断一下这个FLAG, 如果处于reset过程中就跳过waveOutUnprepareHeader. 范例代码:

static CRITICAL_SECTION g_CS;
static BOOL g_bResetting = FALSE;

void Reset()
{
        EnterCriticalSection(&g_CS); //之前InitializeCriticalSection一下
        g_bResetting = TRUE;
        LeaveCriticalSection(&g_CS);

        waveOutReset();

g_bResetting = FALSE; //RESET后就不会调WaveCallbackFunc了，所以不需要锁
}

VOID CALLBACK WaveCallbackFunc(HWAVEOUT hwo, UINT32 uMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
{
       EnterCriticalSection(&g_CS);   //防止g_bResetting在if判断之后, waveOutUnprepareHeader之前被设成1了, callback和reset处于不同线程

        if( (uMsg == WOM_DONE) && !g_bResetting )
        {
                waveOutUnprepareHeader(hWaveOut, pWaveHdr, sizeof(WAVEHDR));
        }

        LeaveCriticalSection(&g_CS);
}

另外, 如果使用了每个BUFFER定长的BUFFER-CHAIN来做生产者-消费者模型, 那么在BUFFER-CHAIN初始化的时候顺便把所有WAVEHDR都PREPARE好, 而只在BUFFER-CHAIN全部释放的时候才做UNPREPARE, 那么在每次waveOutWrite和WOM_DONE的循环里就不需要PREPARE/UNPREPARE了，这也能避开上述情况造成的死锁

第二种死法: 某些人喜欢在在回调处理函数WaveCallbackFunc中，调用waveOutWrite往系统里填充新BUFFER.
错误分析: 同情况一, 在waveOutReset过程中，如果WaveCallbackFunc调用了waveOutWrite, 同样会造成死锁.
解决方法: 同情况一, 设置FLAG和临界区配合来防止. 不过比较建议在另外的线程中调waveOutWrite写入BUFFER, 这才符合生产-消费模型.

第三种死法: 在另外一个线程中调用waveOurWrite, 但是waveOutReset之前, 没有停下那个线程
错误分析: RESET过程中，还有waveOurWrite调用
解决方法: 把waveOurWrite那个线程suspend或退出, 或者在waveOutWrite前面用FLAG+临界区判断

第四种死法: 也是最匪夷所思的死法, 从UI的某个按钮一路调用到waveOutReset(处于同线程中), 而在WaveCallbackFunc中，同线程调用SetWindowText之类UI函数
错误分析: 事实是:
(1) 如果是在WindowProc的某个CASE里调用SetWindowText, 调用者和SetWindowText处于同线程中，那么运行正常, 多数UI也都会这么写;
(2) 如果处于Thread1的UI调用了waveOutReset, 导致处于Thread2中的WaveCallbackFunc运行并调用SetWindowText, 试图设置处于Thread1的UIcallbackProc, 那么SetWindowText会死锁, 导致WaveCallbackFunc死掉, 最后表面上看起来就是waveOutReset死掉．其实我也不明白为什么这样也能死，要问就去问盖茨大叔吧．
解决方法:
在WaveCallbackFunc中，用RESET FLAG + 临界区的方法保护UI调用函数, 使其在waveOutReset过程中不被调用, 或者用PostMessage这样的异步函数，实在不得不同步影响UI的话就忍一忍等waveOurReset函数返回后再做吧.

程序在放音的同时，一旦通过系统的调音量键改变音量大小，程序就会死掉，这和什么有关系？