On Sep 22, 2004, at 4:21 AM, Angelo Fraietta wrote:
Philippe Wicker wrote:
On Sep 21, 2004, at 7:13 AM, Philippe Wicker wrote:
Oops. Made a "little" error in the code. Corrections below :)
On Sep 21, 2004, at 3:01 AM, Angelo Fraietta wrote:
I originally developed an application in Jaguar (using GCC) that
used events and threads. I had the event working so it would wait
for an event for a period of time, and if it did not receive it, it
would return false.
pthread_mutex_lock(&count_mutex);
... Other code
wait_ret = pthread_cond_timedwait(&_eventId, &count_mutex, &tv);
At signaler side:
pthread_mutex_lock(&count_mutex);
// set the predicate: eg increment a counter
pthread_mutex_unlock(&count_mutex);
pthread_cond_signal(&_eventId); // This call may (but do not
need to) be within the lock/unlock
OK - I can see that Now. In my case, I have the event within the
Mutex, however, this is probably unnecessary by me.
At waiter side:
pthread_mutex_lock(&count_mutex);
while (/* predicate evaluates to false */) {
I don't aggree at this point.
If the thread was being awaken by spurious events, the event would be
received early -- not late.
You're right. I should have made my point clearer. I wasn't trying to
explain your actual problem but just to point on a condition variable
misuse. It is necessary to evaluate the predicate *before* calling
condwait because the condition variable has no memory and don't
remember that it has been signaled at some point in the past. It is
also necessary to reevaluate the predicate *after* a wake up to protect
against spurious wake up. Hence the while (! predicate) loop.
What I suspect is happening is the thread is not being released
quickly enough after receiving the event. It is more noticable if I
move the mouse about on the desktop. I am playing a MIDI note every
500ms and I can hear the time not being correct.
Can you tell us some more about the threads that are involved: who is
the signaling thread? How (when) do you decide to signal the waiter?
Are there several synchronization points in the waiter thread? What
thread is sending the midi note?
This only started occuring after upgrading to Panther from Jaguar. I
am after a 5ms resolution. Can Panther offer me this reliably using
POSIX threads?
The OS X scheduler can give very sharp resolution using cond_timedwait,
a 5ms resolution (and even much better) is possible. Now the point is
how is the midi note sender thread scheduled: is it a time shared or a
real time thread? If time shared, did you give it the default priority
or did you try to boost its priority? What is the amount of work it has
to execute when it wakes up?
There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is
VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)
Philippe Wicker
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mt-smp mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
