Prev: Flowcode4 strings?
Next: Infineon EEPROM die
From: Niklas Holsti on 3 Jan 2010 01:22
Tim Wescott wrote:

> * ... I have even seen complaints fired at processors with
> pipelining that the processor's response to instructions is itself not
> deterministic, and it is therefor difficult to assess one's code's
> execution time. These are valid complaints, and I frankly don't know if
> and how they've been resolved.

One approach is to use some kind of program analysis for worst-case
execution time that models the pipeline, and other dynamic "accelerator"
mechanisms such as caches. See
http://en.wikipedia.org/wiki/Worst-case_execution_time.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
From: Paul Keinanen on 3 Jan 2010 03:43
On Sun, 03 Jan 2010 00:13:25 -0600, Vladimir Vassilevsky
<nospam(a)nowhere.com> wrote:

>
>
>Paul Keinanen wrote:
>
>> On Sat, 02 Jan 2010 11:41:38 -0800, Jon Kirwan
>> <jonk(a)infinitefactors.org> wrote:
>>
>>
>>>Many real-time embedded systems know the number of active
>>>processes, as a function of time, beforehand. There is a
>>>clear understanding of what needs to be done, and when, and
>>>the system is designed from the ground up to meet that
>>>requirement.
>>>
>>>So a real-time operating system might have a fixed number of
>>>tasks with fixed schedules, baked into the final binary at
>>>compile-time. In this case, everything is known a priori.
>>
>>
>> Many small simple real time kernels have a bit mask for up to 8, 16 or
>> 32 tasks. When a task becomes runable e.g. due to an interrupt, the
>> ISR sets the corresponding bit in the bit mask.
>
>If the speed of scheduler and the context switching time does matter, it
>usually means poor design. Normally, system needs draw insignificant
>amount of time, so if the context switching time is fixed or dependent
>on the number of tasks, etc. is irrelevant.

There is always the question of division of labor between the
interrupt service routine and some high priority "handler" task.
Especially if the hardware does not properly support nested interrupt
handling, it would ne desirable to move some of the heavier processing
to a high priority task. In this sense, the time taken for the
complete task switching is important.

Of course, if the task switching is very expensive, it does not make
sense to perform any task switching and instead do most of the time
critical processing in the ISR, which will cause other problems, if
there are multiple interrupt sources and no interruptible ISRs.

From: Frank Buss on 3 Jan 2010 05:31
Paul Keinanen wrote:

> To find the next task to run, just find the most significant bit that
> is set and execute the corresponding task. If the processor has
> FindFirstBitSet type instructions, this is trivial.

There are some interesting ideas on this page, if your CPU doesn't have
such an instruction:

http://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObvious

--
Frank Buss, fb(a)frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Boudewijn Dijkstra on 4 Jan 2010 10:21
Op Sat, 02 Jan 2010 18:48:58 +0100 schreef brOS <bogdanrosandic(a)gmail.com>:
> I have just read David Kalyinsky's article which can be found on
> following link
> http://www.jmargolin.com/uavs/jm_rpv2_npl_16.pdf ...

I had almost forgotten about Jed Margolin.

> What confuses me is part of the article named "fixed time task switching"
> and figure number 4. It says that real time OS have constant context
> switching time (including time for finding task with highest priority).
> What I am confused about is how can it be constant if number of tasks in
> systems grows. Of course kernel can be implemented in such a way that
> lists which contain TCB are sorted. If this is the case then scheduler's
> job is
> just to take first TCB from the list and then do dispatching. But in that
> case functions that moving TCB from waiting or suspendin lists back to
> ready list should do that sorting. So scheduler execution time is
> constant,
> but overhead is introduced when calling sorting functions, and execution
> time of these functions are not deterministic...

Sorting is not necessary when keeping a ready-list per priority. Then you
could use a bit mask of all priorities to keep track of the highest
priority ready-list that is non-empty.

> I dont think that Mr Kalinsky is right about this. In my opinion
> something
> has to depend of number of tasks in system. It can be scheduler execution
> time or execution time of kernel functions which sorts TCB ready list....
> Am I wrong about this?
>


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
First  |  Prev  | 
Pages: 1 2
Prev: Flowcode4 strings?
Next: Infineon EEPROM die