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: Godfrey van der Linden <email@hidden>
- Date: Thu, 16 Sep 2004 16:02:58 -0700
Priority inversions are always a problem, I didn't realise you were
talking about a "real-time" thread. All I can say is that this
technique has a good probability of success 'cause the lock is only
held for very, very short periods AND when we get priority handoff
working out in user land it will definitely be presented through the
pthread_mutex. (This is not a promise, I do not work in that part of
Apple that would implement this API, I'm just making a guess based on
the in kernel capabilities of mutex_lock())
If you need TRUE priority hand-off between a pair of thread then you
will need kernel support and you will have to pay the cost of a kernel
transition for every attempt to take a lock, this is probably not
desirable either, though that is basically the mach_ipc solution.
Godfrey
On Sep 16, , at 15:53, Stéphane LETZ wrote:
On 16 sept. 04, at 23:11, Godfrey van der Linden wrote:
Oops, sorry I forgot to signal the condition in enqueue should read
void enqueue: (queue_entry_t) record
{
// Note no allocation to hold us up - it is assumed that the
client has done the allocation itself
pthread_mutex_lock(&queueLock);
enqueue(&queueHead, record);
pthread_cond_signal(&queueSleeper);
pthread_mutex_unlock(&queueLock);
}
Also a small optimisation would be to track if you have any sleepers
behind the dequeue and only do a signal if sleepers > 0.
OK Thanks.
But what about the "priority inversion" problem? It a time-constraint
writer thread is blocked on the "pthread_mutex_lock" done by a
lower-priotity reader thread?
Thanks
Stephane Letz
_______________________________________________
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