[lkml]   [2002]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.112 / U:4.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site