Re: Using MIG RPC between 2 threads inside a process
Re: Using MIG RPC between 2 threads inside a process
- Subject: Re: Using MIG RPC between 2 threads inside a process
- From: Paul Forgey <email@hidden>
- Date: Sat, 18 Sep 2004 13:01:48 -0700
In this case, I don't think it makes too much difference either. In
general, I'd say make a habit of signaling the conditional while
holding the mutex. Since conditionals have no state, the intention for
pairing them with mutexes is to insure somebody is around to block on
the conditional when it's signaled if you acquire the mutex before
doing so.
Here the mutex is released in the consumer thread while it isn't
dealing with the queue or waiting for the conditional. This is good
because other producer threads could otherwise needlessly block. Since
it is properly looping on the predicate (CheckMyCondition()), which
does have state, it can get away with doing that.
On Sep 18, 2004, at 2:01 AM, Steve Checkoway wrote:
A client might or might not loop over and over but one thing you
forgot was to unlock after you signal.
pthread_mutex_lock(&lock);
DoSomeWork();
pthread_cond_signal(&cond);
pthread_mutex_unlock(&lock);
It might be better to signal after unlocking but since
pthread_cond_signal doesn't wake up the other threads right away, I'm
not sure it makes a difference. I'll bet someone here could say which
way is best.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden