This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: Re: how to implement EDF scheduling in eCos


Hello Friedrich,

I think you forgot to reply to the mailing list, so I hope it's ok to
forward your message.

Ciao, Fabian


---------- Forwarded message ----------
From: Friedrich Schick <Friedrich.Schick@web.de>
Date: 2010/1/14
Subject: Re: [ECOS] Re: how to implement EDF scheduling in eCos
To: Fabian Scheler <fabian.scheler@gmail.com>


Hello,

Something you might consider when you are writing an EDF scheduler.

There are two types of tasks, event and time based. Lets call them
e_task and t_task. E_tasks are like a CAN message, which occurs on a
none regular basis, while t_task are more like a FlexRay message,
which do have a certain deadline.

I would consider following scheduling algorithm. You have three eCos
threads. The first e_thread is to handle all e_tasks, the second
t_thread to handle all t_tasks and the last one is the does some
background processing.

The are following fixed priorities to schedule (0 is the lowest).

4?? ?time_high
3?? ?event
2?? ?time_low
1?? ?background
0?? ?idle

Starting scheduling the t_thread has the priority time_low, the
e_thread the priority event. If no e_task is waiting the t_tasks are
processed. But if an event occurs there is a switch to the e_thread.
The t_thread has a deadline (which is the sum of all
t_tasks-deadlines). If this deadline is to be missed, t_threads
priority will be increased to time_high. After the t_thread has
processed all t_tasks, it switches back its priority to time_low.

? Locking

What about mutexes? EDF scheduling does not need any mutexes (per
definition), but since we are mixing scheduling-algorithm there must
be a support of mutexes. The easiest way to support mutexes (and not
running in priority-inversion) is to set the mutex-locking thread to
the a new priority level (5 mutex).

But regarding device drivers (DSR), you should consider scheduler_lock.

? Ethernet

The ethernet might be handled as a t_task.

? Implementation

The EDF-scheduling is all done in thread context (so you do not have
to write a completely new scheduler). To enable the EDF-scheduling
there must be a timer interrupt which invokes the priority switch.


Best regards,

Friedrich



On Thu, Jan 14, 2010 at 7:50 AM, Fabian Scheler
<fabian.scheler@gmail.com> wrote:
>
> Hi Nodir,
>
> > My approach is adding two more additional fields to thread's
> > properties. Those are:
> > cyg_tick_count_t wcet /*worst case execution time*/
> > cyg_tick_count_t deadline /* absolute deadline thread to be finished */
>
> is that deadline provided by the application or is it computed by the
> scheduler. In the first case a relative deadline might be easier to
> handle, the scheduler than needs to map that relative deadline to an
> absolute one.
>
> Ciao, Fabian
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]