Joerg-Cyril.Hoehle@t-systems.com a écrit :
Hi,
I need some information about threads and callbacks. I already found out that:
SetEvent delivers "asynchronously" and can unblock threads WaitingForMultipleObjects. No callback is involved (which does not mean that the current thread cannot be preempted by another one awakening). Therefore, this seems strange: LeaveCriticalSection(&wma->cs); SetEvent(wma->hStopEvent); EnterCriticalSection(&wma->cs); I mean, if you left it, anything can have happened in between (including close of the device).
Likewise, notifications (to either thread or window) deliver asynchronously as well, to a message queue. No callback is involved.
OTOH functions like waveOutReset will callback into the applications (via Un-/PrepareBuffer etc.). In this example, LeaveCriticalSecion seems necessary, because waveOutReset does everything on the caller's thread, which might cause a driver to be entered recursively. LeaveCriticalSection(&wma->cs); dwRet = waveOutReset(wma->hWave); EnterCriticalSection(&wma->cs); HOWEVER, Critical sections can be re-entered by the same thread. They are no inner-thread protection. Why then leave it? Is the Critical section adequate at all? What else is useable?
Is it allowed for an application to call waveOpen in one thread and then call waveOut, waveStart, waveAddBuffer etc. from another one?
Is it allowed to mmioSeek/mmioRead from different threads using the same handle?
Thanks for your help, Jörg Höhle
the best answer to all of these questions is: write some tests !
regarding the question 1/, yes it maybe that wma no longer refers to a correct object. to handle properly you need to add ref counting to the object
regarding item #3, it doesn't protect against reentrancy, it will allow the current object to be accessible if another thread tries to use it while the first thread is in the middle of a notification MSDN documentation says:
Applications should not call any system-defined functions from inside a callback function, except for *EnterCriticalSection*, *LeaveCriticalSection*, *midiOutLongMsg*, *midiOutShortMsg*, *OutputDebugString*, *PostMessage*, *PostThreadMessage*, *SetEvent*, *timeGetSystemTime*, *timeGetTime*, *timeKillEvent*, and *timeSetEvent*. Calling other wave functions will cause deadlock.
(but don't take every MSDN word for granted, write tests!!!)
so the code out of mciavi32 seems rather sane to me, as it will not block access to the ressource while processing the callback, even if not 100% necessary
so globally, the functions must be multi-thread safe and reentrancy requires some testing
A+