Re: Reading midi events from device
Re: Reading midi events from device
- Subject: Re: Reading midi events from device
- From: Kurt Revis <email@hidden>
- Date: Sun, 12 Nov 2006 13:17:35 -0800
On Nov 12, 2006, at 5:22 AM, Jacob Ole Juul Kolding wrote:
Now I have a problem where the callback function for reading the
packages stops responding after a number of packages <50.
The number of packages recived before the callback stops is random
from run to run.
The callback looks like this:
static void MyReadProc(const MIDIPacketList *pktlist, void *refCon,
void *connRefCon)
{
while(((MidiSource*)(refCon))->processing){}
((MidiSource*)(refCon))->readingpack = true;
// do some stuff
((MidiSource*)(refCon))-> packages.push_back
(datapack);
((MidiSource*)(refCon))->readingpack = false;
Since you didn't show what a MidiSource is, it's difficult to say.
Probably if you take out everything that touches that, it will work
fine (you'll see the printf output).
One possibility is that 'processing' (whatever that is) is getting
stuck on, causing your read proc to stay in the while loop forever.
You could very easily verify this by setting a breakpoint in the
debugger.
Anyway, this while loop is absolutely the wrong way to do things.
Please do some reading about thread programming -- you have a "busy
wait" here that does nothing but waste CPU.
It doesn't prevent the two threads from stepping on each other,
either. Consider this case (where thread 1 is the MIDI thread where
MyReadProc() is running, and thread 2 is your other thread):
1) Thread 2 sets processing to false
2) Thread 1 ends the while loop
3) Thread 2 sees that readingpack is still false, and goes on to
touch packages
4) Thread 1 sets readingpack to true, and touches packages
Both threads are trying to use 'packages' at the same time, and
assuming it's a non-thread-safe STL data structure, it probably gets
corrupted.
If you want to prevent two threads from touching the same data at the
same time, use a mutex. You could also use some fancy lock-free data
structure to get better results, but start with the mutex first...
--
Kurt Revis
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden