2009-12-09 31 views
3

我找不到關於waveOut API線程安全性的任何信息。waveOut(Win32API)和多線程

我創造新的waveout的手柄後,我有這些線程:

主題1:緩衝處理。使用這些API函數:

  • waveOutPrepareHeader
  • waveOutWrite
  • waveOutUnprepareHeader

線程2:桂枝,控制器線程。使用這些API函數:

  • waveOutPause
  • waveOutRestart
  • waveOutReset
  • waveOutBreakLoop

這兩個線程都在使用的同時同waveout的手柄運行。 在我的測試中,我沒有看到任何功能問題,但並不意味着它是安全的。

這個架構是線程安全的嗎? 是否有關於waveOut API的線程安全性的任何文檔? 關於waveOut API線程安全的其他建議?

謝謝。

+0

您應該在使用waveOut API執行任何操作之前閱讀此內容:http://stackoverflow.com/questions/195696/why-would-waveoutwrite-cause-an-exception-in-the-debug-heap – 2009-12-18 23:33:11

回答

4

一般來說,waveOut API應該是線程安全的。因爲通常waveOutOpen()會創建自己的線程,所有waveOut *函數都會將消息發送到該線程。但我不能給你一個證明......

但是,你可以改變你的應用程序,使其在任何情況下,安全:

  1. 啓動緩衝器管理線程,從GUI線程調用記得dwBufferThreadId
  2. waveOutOpen with dwCallback設置爲dwBufferThreadId和fdwOpen到CALLBACK_THREAD
  3. 您的緩衝區管理線程:「waveOutWrite」提前一些緩衝區,GetMessage循環()
  4. waveOutOpen將發送一個WOM_DONE,只要緩衝區完成並且需要一個新的緩衝區,這是瞬間從該線程中waveOutWrite一個新的緩衝區
  5. 作出waveOutPause,waveOutRestart您的通話等從GUI線程(沒有在MSDN說反對的話,所有的例子做到這一點,即使緩衝區將從另一個充滿線)

example 1

如果你想成爲100%的把握,你可以只抓住一個窗口消息(WM_USER + 0),並調用PostThreadMessage(WM_USER+0, dwBufferThreadId, MY_CTL_PAUSE,0),然後根據你的緩衝線程接收消息,您在那裏撥打waveOutPause()。 Windows消息隊列爲您節省了一些編寫自己的消息隊列的工作;-)

+0

如果您使用有些變量需要跟蹤已用緩衝區的數量,因此將共享鎖定(回調具有優先級)放在它們上面並從緩衝區下溢中添加恢復(下溢有時可能發生在小延遲配置下)是一個好主意,這對我的多線程程序...並且還消除了這種混淆/干擾噪音 – Spektre 2013-09-20 14:02:16

+0

你不能使用WM_USER + 0:由於某種原因,waveOutOpen(),waveOutWrite()等正在向我的音頻線程的GetMessage()發送WM_USER + 0(1024) ,除了它們被記錄爲發送的消息之外。 – 2016-03-25 16:32:36

2

我沒有看到任何文檔,但我無法想象對waveOutWrite的調用將被認爲是安全的,可以在同一個句柄上同時調用WaveOutRestart。

如果你使用VS2010 Beta2中我會看各種的演練爲Agents Library,並試圖把它變成你在哪裏傳遞消息像寫,暫停,重新開始一個生產者消費者問題,等等

如果你沒有使用Visual Studio 2010(或者不能)我鼓勵你找到一種方法將它分解成生產者消費者問題,使用線程和某種內部同步隊列來存儲命令進行處理。如果消息不是那麼頻繁,並且假設你只有2個線程在這個隊列上工作,那麼你可以在std ::隊列周圍放置一個普通的舊Win32臨界區...

hope這有助於。

1

它可能是線程安全的,但如果您(或我)找不到任何官方文檔說明它是線程安全的,那麼假設它不是' t並添加您自己的線程同步。輕量級的EnterCriticalSection/LeaveCriticalSection實現可能不超過十幾行代碼。

沒有任何測試可以向您保證API是線程安全的:問題可能只發生在某些CPU或總線速度或某些聲卡的架構上。你(不是微軟)都沒有能力測試所有可能的配置。

你也應該不會做出什麼微軟或英特爾或聲卡製造商或驅動程序編寫者將在未來的某個實現做任何假設。