Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Ingo Molnar]

* Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:

> however, i don't agree that futexes are conceptually superior. they
> don't express the intended operation nearly as accurately as
> yield_to(tid) would. the operation is "i have nothing else to do, and
> i want <tid> to run next". a futex says "this particular condition is
> satisfied, which might wake one or more tasks". [...]

what i suggested was to use one of the pthread APIs - not to use raw
futexes.

so the basic model is that you have a processing dependency between
threads, correct? If one thread finishes, you know which one should come
next - based on the graph. The first thread is triggered by some
external event. (timer or audio event.)

this can be cleanly implemented by attaching a pthread spinlock to each
node of the graph, and initializing the lock to a locked state. The
threads go sleeping by 'taking the lock'. The one that does processing,
wakes up the next one by unlocking that graph node, and then it goes to
sleep by locking its own node.

(it would be cleaner to use POSIX semaphores for this, but you mentioned
the requirement for the mechanism to work on 2.4 kernels too - pthread
spinlocks will work inter-process on 2.4 too, and will schedule nicely.)

> [...] its still necessary for the caller to go to sleep explicitly,
> its still necessary for the tasks involved to know about the futexes,
> which actually are really irrelevant - there are no conditions to
> satisfy, just a series of tasks we want to run.

well, no. Unless i misunderstood your application model, you want
threads to sleep until they are woken up. So you want a very basic
sleep/wake mechanism. But yield_to() does not achieve that! yield_to()
will yield to _already running_ (i.e. in the runqueue) threads. Using
yield() (or yield_to()) for this is really suboptimal. By using a futex
based mechanism you get a very nice schedule/sleep pattern.

(you could also use kill()/sigwait(), but that is slower than futexes.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/