On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:Well, but it does happen in reality :)In a system, we typically look at a set of tasks. In Linux-kernelThis would be true in the original Liu&Layland model (where a task blocks
terminology, a particular task is normally a thread. When a thread is
ready to run, we say that a *job* of that task is running.
only when a job finishes), but I do not think it is correct in a real system...
For example: (notice: this discussion might be slightly off-topic, and I do not
think this should go in the document... I am writing just to clarify my point
- Let's consider a (over simplified) video decoder as an example of task
- The task periodically read a video frame (from disk or network), decodes it,
and displays it
- So, each job starts when the frame is read, and finishes when the frame is
displayed. And jobs are (in this case) activated periodically
- During the execution of a job, the task might invoke a blocking system call,
and block... When it wakes up, it is still in the same job (decoding the same
video frame), and not in a different one.
This is (IMHO) where all the confusion comes from.
I would strongly urge you not to use that as an example, because its
dead wrong design. An RT thread (be it RR,FIFO or DL) should _NEVER_ do
Have !RT tasks read the stuff from disk into a buffer, then let the RTOk.
task read data from the buffer and flip frames and such.
If you want to mention blocking, then please use the most common one:
blocking on a (hopefully PI) mutex.
On the other subject; I wouldn't actually mind if it grew into a properOk... My point was that it would be better (IMHO) to first explain how
(academic or not) summary of deadline scheduling theory and how it
Sure, refer to actual papers for all the proofs and such, but it would
be very good to go over all the bits and pieces that make up the system.
So cover the periodic, sporadic and aperiodic model like henr_k
suggested, please do cover the job/instance idiom as it is used all over
Then also treat schedulability tests and their ramification, explainOk.
what laxity is, what tardiness is, that GEDF doesn't have 0 tardiness
but does have bounded tardiness.
Maybe even mention the actual bounds -- but refer to papers for their
Mention CBS and the ramification etc..
Yes this is all a bit much, but I feel it is important, after all howOk.
can you properly use something you don't understand? (and yes I know its
a very popular thing to not want to understand how things work but still
use them :-/).
I mean, I'm the kind of idiot that actually goes out and read a bunch of
papers, but many people simply cannot read those things, or are not
given the time to, even if they wanted and could (arguably they have