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: Mike Smith <email@hidden>
- Date: Thu, 16 Sep 2004 18:11:35 -0700
On Sep 16, 2004, at 12:02 PM, email@hidden wrote:
It works best when you combine the queue with the concept of
'ownership'. That is your 'client' thread allocates the 'record',
initialises it and enqueues it. It agrees that it is not allowed to
deal with the record until it gets returned to it on it's own queue,
the only function that is allowed to operate on it is an 'abort'
function if that is meaninngful.
Another problem for me is that the thread which has things to enqueue
is a time-constraint thread. I guess locking the pthread_mutex can
cause priority inversion problems that I can not afford.
This is why using this inter-thread *asynchonous* RPC mechanism, i was
thinking that I could also avoid the priority inversion problem.
What makes you think that the kernel has a lockless queue mechanism?
There are a number of relatively asynchronous handoff techniques that
you
could use, however fundamentally you have to accept that if your
real-time
thread depends on other, non-real-time components, you cannot
guarantee real-time behaviour.
If your queueing thread is the RT thread, then you should use
pthread_mutex_trylock
to obtain the queue lock, and if the lock op fails put the queued
object onto a
private deferred list and attempt to queue it again next time. This
will prevent you
from blocking behind the queue just because the dequeuer holds the lock
on
an empty or almost-empty queue. At this point, your only potential
blocker is the
source of queue objects.
= Mike
_______________________________________________
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