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


Groups > comp.arch.embedded > #29086

Re: From cooperative to preemptive scheduler: a real example

From pozz <pozzugno@gmail.com>
Newsgroups comp.arch.embedded
Subject Re: From cooperative to preemptive scheduler: a real example
Date 2020-01-09 12:19 +0100
Organization A noiseless patient Spider
Message-ID <qv7286$8cb$1@dont-email.me> (permalink)
References <qv0lmu$up1$1@dont-email.me> <h7iqr4F6k9uU1@mid.individual.net> <qv32lj$ko6$1@dont-email.me> <h7n4tfF3sqmU1@mid.individual.net>

Show all headers | View raw


Il 08/01/2020 23:54, Niklas Holsti ha scritto:
> 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.

Ah yes, interrupts are preemptive and I use them a lot, but they are 
confined in their works, they are very lightweight and fast.

The discussion here regards medium to high complexity tasks.

> 
> 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.
> 

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