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 16:50:45 -0700
I know this is starting to stray off the original question, but I just
realized you will indeed want to signal while the mutex is being held,
and it's for the same reasons I gave that you want to make it a habit
to do so.
If you happen to signal the conditional between the CheckMyCondition
and pthread_cond_wait, the consumer will go into the wait with requests
in the queue. Signal while holding the mutex and two things will
happen: the consumer will notice work in the queue before waiting, or
it will be waiting.
On Sep 18, 2004, at 1:01 PM, Paul Forgey wrote:
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
_______________________________________________
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