Messages in this thread | | | Date | Thu, 21 Mar 2002 07:48:43 +0100 | From | Martin Wirth <> | Subject | Re: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) |
| |
Rusty Russell wrote:
>2) Where this is suboptimal,
Up to know I was too focused on the wait functions, but there is also a problem with cond_broadcast (and the mutex-protected version of cond_signal): since they may block (on ack or lock) this opens up chances for priority inversion like problems. I think to be really usefull cond_broacast and cond_signal should have a non-blocking behaviour with predictible runtime.
Just to convince you that this is a real world problem here is a description of one of my data-aquisition programs:
A 'producer' thread waits for the trigger of a transient recorder at 500 Hz IRQ-rate, reads out 64k on each event into a large circular buffer, calls cond_broadcast (every 5th IRQ) without holding a mutex and goes to sleep to wait for the next IRQ. (This thread is SCHED_FIFO)
Then there are three (SCHED_OTHER) 'consumer' threads which work on the same data doing different things of different importance (group them according to some hardware parameter and store them into different files, calculate averaged powerspectra, select pieces for an online scope-like display etc.)
If in this scenario the producer would have to wait in cond_broadcast until the least prio consumer has acknowledged (which may take a timer tick or longer) he would lose several IRQs each time.
So for my applications a cond_broadcast blocking for the waiters is simply not acceptable.
Martin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |