wxMutex always yields

[Matt Connolly]

I'm doing an app that plays an audio file, but the audio playback is  
controlled by commands sent to a queue which is protected by a wxMutex  
lock so that the main thread can issue commands to the audio thread.

However, I'm noticing that in the audio thread, when I lock the queue  
to check if there are any events, the thread always yields. This means  
that even when a machine is 80% idle, the audio playback is  
ridiculously slow, since the thread's processing always gets deferred  
by the yield. I can see that in the mac (carbon) implementation, there  
is a MPYield() call in the implementation of wxMutexInternal.

I've noticed the same sympton on Windows machines, so I assume that  
this is there to emulate how locks work on windows, or something.


Also, I was wondering why it is that *nearly* all of the mac calls are  
still based on the old carbon MP library and not using the faster  
darwin pthreads library?


Perhaps, then, I should rework my queue to use a counting semaphore to  
represent the number of items in the queue, and the lock is only  
performed in the audio thread if there is guaranteed to be an item in  
the queue to process..... this still gives me a yield though, which sux.

Any thoughts of another way around this?


-Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2174 bytes
Desc: not available
Url : http://lists.wxwidgets.org/pipermail/wx-users/attachments/20071129/2d5689a6/smime.bin