site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com 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 OK Thanks. Thanks Stephane Letz _______________________________________________ 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... 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. 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. 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? This email sent to site_archiver@lists.apple.com