Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #29081

Re: From cooperative to preemptive scheduler: a real example

From Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups comp.arch.embedded
Subject Re: From cooperative to preemptive scheduler: a real example
Date 2020-01-09 00:54 +0200
Organization Tidorum Ltd
Message-ID <h7n4tfF3sqmU1@mid.individual.net> (permalink)
References <qv0lmu$up1$1@dont-email.me> <h7iqr4F6k9uU1@mid.individual.net> <qv32lj$ko6$1@dont-email.me>

Show all headers | View raw


On 2020-01-08 1:02, pozz wrote:
> Il 07/01/2020 08:38, Niklas Holsti ha scritto:
>> On 2020-01-07 3:08, pozz wrote:
>>> I noticed my previous post about preemptive OS involved many people 
>>> and started many discussions, most of them theoric.
>>>
>>> Someone wrote the synchronization of tasks in preemptive scheduler is 
>>> not so difficult, after understanding some things. 
>>
>> I made some such statement.
>>
>>> Others suggested to abandon at all preemptive scheduler, considering 
>>> its pitfalls.
>>>
>>> Because I know my limits, I don't think I can produce a well-written 
>>> preemption system. However I'd like to understand a little more about 
>>> them. Starting from an example.
>>>
>>> Suppose my system is a display where a message is written. The 
>>> message can be customized by a serial line.
>>
>> So, this system consists of a display and a serial input line and has 
>> requirements as follows:
>>
>> 1. The display shall at all times show a message, of at most 31 
>> characters.
>>
>> - To be defined: what the initial message should be at system reset.
>>
>> 2. The SW shall receive characters from the serial line, buffering 
>> them in a "frame buffer" in memory, which can hold up to 64 characters.
>>
>> 3. After each received (and buffered) serial-line character, the SW 
>> shall check if the buffered characters form a complete "frame".
>>
>> - To be defined: what to do if the frame buffer is full but does not 
>> form a complete frame. (This may of course be impossible by design of 
>> the "frame_is_complete" function.)
>>
>> 4. When the buffered characters form a complete frame, the SW shall 
>> convert (decode) the contents of the frame into a message, of at most 
>> 31 characters, display that message until another, new frame is 
>> received, and erase the frame-buffer in preparation for the next frame.
>>
>> The real-time aspects are undefined, except that each message is 
>> displayed until the next frame is received.
> 
> The only real-time is that the new message sent through the serial line 
> appears on the display in a reasonable time: 100ms? 1s? Something similar.
> 
> The second requirement is that the display mustn't show a hybrid message 
> composed by two parts of the successive messages.
> 
> 
>>> In cooperative approach, I would write something:

    [snip code]

>>> How to convert these two tasks in a preemptive scheduler? Which 
>>> priority to assign to them?
>>
>> Before that conversion one must think about the real-time 
>> requirements: deadlines, response-times. This is difficult for this 
>> example, because you have not stated any requirements.
>>
>> Let's assume these requirements and properties of the environment:
>>
>> A. The function "serial_rx" polls the one-character reception buffer 
>> of the serial line once, and returns the received character, if any, 
>> and EOF otherwise. It must be called at least as often as characters 
>> arrive (that is, depending on baud rate) to avoid overrun and loss of 
>> some characters.

You asked about possible advantages of pre-emption; I made my 
assumptions, above, such that the (incomplete) example you gave shows 
this advantage, under these assumptions (which could be true for other, 
otherwise similar example applications).

> No, serial driver works in interrupt mode and already use a FIFO buffer, 
> sufficiently big. serial_rx() pop a single element from the FIFO, if any.

Ah, then your *system* is intrinsically pre-emptive (the interrupts 
pre-empt the tasks), even if the *code you showed* does not show this 
pre-emption.

I won't reply to your other comments on my assumptions, as they are 
irrelevant to the point of where and when pre-emption can be good for you.

> Serial driver interrupts guarantees no loss of input during 
> display_printat() or other functions.

Right, because it is pre-emptive. So there you see the advantage.

>> For "task_display", you could replace the "refresh is needed" flag 
>> with another semaphore, which is initially zero, is "given" in 
>> "task_serial" when a new message is to be displayed, and is "taken" by 
>> "task_display" before it displays the new message. Then "task_display" 
>> consumes no processing resources until it actually has to.
> 
> I was thinking to a refresh made at regular intervals, such as every 100ms.

In some systems that could result in annoying flickering of the display, 
which could even be dangerous (seizure-inducing) to some users.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-07 02:08 +0100
  Re: From cooperative to preemptive scheduler: a real example Don Y <blockedofcourse@foo.invalid> - 2020-01-06 19:37 -0700
    Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-07 10:11 +0100
      Re: From cooperative to preemptive scheduler: a real example Don Y <blockedofcourse@foo.invalid> - 2020-01-07 07:51 -0700
        Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-07 23:51 +0100
          Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-09 01:39 +0200
            Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-10 00:42 +0100
              Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-15 18:39 +0200
          Re: From cooperative to preemptive scheduler: a real example Don Y <blockedofcourse@foo.invalid> - 2020-01-08 23:12 -0700
            Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-10 00:49 +0100
          Re: From cooperative to preemptive scheduler: a real example Don Y <blockedofcourse@foo.invalid> - 2020-01-08 23:12 -0700
          Re: From cooperative to preemptive scheduler: a real example Don Y <blockedofcourse@foo.invalid> - 2020-01-09 01:33 -0700
  Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-07 09:38 +0200
    Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-08 00:02 +0100
      Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-09 00:54 +0200
        Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-09 12:19 +0100
          Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-09 14:03 +0200
            Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-10 00:32 +0100
              Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-15 18:53 +0200
                Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-16 14:48 +0100
                Re: From cooperative to preemptive scheduler: a real example upsidedown@downunder.com - 2020-01-16 21:04 +0200
                Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-16 22:24 +0200
                Re: From cooperative to preemptive scheduler: a real example pozz <pozzugno@gmail.com> - 2020-01-17 02:05 +0100
                Re: From cooperative to preemptive scheduler: a real example Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-18 23:03 +0200
  Re: From cooperative to preemptive scheduler [Stack] pozz <pozzugno@gmail.com> - 2020-01-14 13:27 +0100
    Re: From cooperative to preemptive scheduler [Stack] Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-14 20:10 +0100
      Re: From cooperative to preemptive scheduler [Stack] pozz <pozzugno@gmail.com> - 2020-01-15 09:36 +0100
        Re: From cooperative to preemptive scheduler [Stack] Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-01-15 11:30 +0100
          Re: From cooperative to preemptive scheduler [Stack] pozz <pozzugno@gmail.com> - 2020-01-15 11:51 +0100
        Re: From cooperative to preemptive scheduler [Stack] Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-15 21:51 +0100
    Re: From cooperative to preemptive scheduler [Stack] Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-15 21:26 +0200
      Re: From cooperative to preemptive scheduler [Stack] Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-15 22:12 +0100
        Re: From cooperative to preemptive scheduler [Stack] Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-15 23:30 +0200

csiph-web