Content deleted Content added
→advantages of this model: link to explanation of find first one |
m Maintain {{WPBS}} and vital articles: 1 WikiProject template. Create {{WPBS}}. Keep majority rating "Stub" in {{WPBS}}. Remove 1 same rating as {{WPBS}} in {{WikiProject Computing}}. Tag: |
||
| (6 intermediate revisions by 4 users not shown) | |||
Line 1:
{{WikiProject
{{WikiProject Computing|science=yes}}
}}
==Untitled==
In my opinion it is wrong to ''say advantage of making sure no task hogs the processor for any time longer than the time slice''
fixed priority means only the highest priority thread will run.
:I agree; "priority" implies that you want some tasks to run first. You have to realize that trying to squeeze too many tasks into a r-t system can get you in trouble. A lot of papers have been written about how to guarantee that all critical tasks will always complete on time, but it may be more useful to advise practitioners to aim for no more than about 50% r-t utilization.
:A lot of designers try to cover problems by leaving interrupts off. This leads to systems which have potentially large interrupt latency and as a consequence a high variance in that value. Among other problems, this leads to systems that cannot guarantee effectively uniform sampling times, which violates one of the basic assumptions of most digital signal processing algorithms.
:--[[User:AJim|AJim]] ([[User talk:AJim|talk]]) 17:47, 26 May 2012 (UTC)
Why are we talking about "real-time"? If the system has to allocate the cpu to a task for some time (since there are less cpus than processes/tasks), it's more "time slicing" ... (http://en.wikipedia.org/wiki/Preemption_(computing)#Time_slice ) [[User:Zenkutsu|Zenkutsu]] ([[User talk:Zenkutsu|talk]]) 05:52, 20 March 2013 (UTC)
:Perhaps I misunderstand you, but I think you may have taken too narrow a definition of "real time". I think of time slicing in situations where the processor allocation is rotated between some number of very long computations, each with run times much longer than a slice, so that they all appear to be making progress, all at a reduced rate. I think of real time as implying that a computation is being performed in synchronism with events in the real world outside the computer. Consider what I think is a fairly common design, a digital simulation of an analog controller in an embedded system. It takes samples and provides updates frequently enough to satisfy the [[Nyquist–Shannon sampling theorem|anti-aliasing criteria]] of the analog system. This "task", the servo simulation thread, might never end, but the "process" it supports runs in real time, performs each update on schedule, then waits to be triggered again for the next update. Just like with a priority interrupt system, the thread can be suspended temporarily to allow even more time-critical work to run, and, when it is time for it to perform an update, it can temporarily suspend any less time-critical work. The amount of time it gets is not determined by an independent "time slice" parameter, it is determined by the time it takes to complete the next update, so that it keeps in sync with the outside world (to which it appears to be an analog circuit). The lowest priority task, or thread, is ultimately the one that gives up some of its allocated time to let this happen. Instead of hardware interrupts, we might have software events, semaphores say, that trigger the updates, although in this example they would be synchronized to a time source or external event of some sort. By the way, I also think that most systems that employ time slicing only guarantee that a slice is the longest continuous time a computation will get, and that a computation generally also looses control whenever it needs to wait for an external event such as receiving the next bucket of data from a file.
:--[[User:AJim|AJim]] ([[User talk:AJim|talk]]) 20:57, 20 March 2013 (UTC)
== advantages of this model ==
| |||