site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Sep 16, 2004, at 12:02 PM, darwin-dev-request@lists.apple.com wrote: '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? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... It works best when you combine the queue with the concept of 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. This email sent to site_archiver@lists.apple.com