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

Groups > comp.arch.embedded > #29106

Re: From cooperative to preemptive scheduler: a real example

Show all headers | View raw

Il 15/01/2020 17:53, Niklas Holsti ha scritto:
> On 2020-01-10 1:32, pozz wrote:
>> Il 09/01/2020 13:03, Niklas Holsti ha scritto:
>>> On 2020-01-09 13:19, pozz wrote:
>>>> 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:
>>>
>>>     [snip]
>>>
>>>>>>> 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.
>>>
>>> That's a design decision. Some systems do most of their work in 
>>> interrupt handlers, and use "background" processing only for some 
>>> non-critical housekeeping tasks.
>>>
>>
>> Yes, I imagine there are a pletora of possibilites. Anyway I thought 
>> there was two typical approaches: superloop that continuously calls 
>> non-blocking functions (an example of cooperative scheduler) and a 
>> full preemptive scheduler (most of the time a full RTOS).
> 
> The approach where all real-time "tasks" are interrupts is called 
> "foreground-background", I believe. It was popular in the microcomputer 
> era, before real-time kernels became popular -- it gave most of the same 
> benefits (pre-emption) but scheduled by HW (interrupt priorities).

Yes "foreground-background" is another name, but it says nothing about 
the blocking/non-blocking of background (non interrupts) tasks.
If you have blocking (long running) tasks, you will not have a reactive 
system (only interrupts will be reactive).
If the tasks are coded as non-blocking (maybe with the help of 
state-machines), you will be able to have a reactive system even for the 
non-interrupts tasks.

>> Interrupts are always present, even in superloop.
> 
> Again a design choice. Some critical systems don't want *any* 
> pre-emption, even by interrupts -- simplicity reigns. So they poll, and 
> accept the performance hit. For example, some colleagues of mine 
> recently completed the "recovery SW" for ESA's ExoMars rover, which 
> takes over if the "real" SW crashes and is intended to be super-safe and 
> just support problem analysis and recovery. Using any kind of real-time 
> kernel was forbidden -- only sequential coding was allowed. Any new, 
> nice SW "feature" that my colleagues suggested, for example to speed up 
> communication with Earth, was denied by the customer because it would 
> complicate the SW a little bit -- perhaps one more conditional 
> statement. No-no.

I don't think this is an example that can be considered "typical" and I 
know there are "extreme cases" where a singular approach is needed.


>> Maybe I am wrong, but I implement ISRs with great care and attention,
> 
> Of course you are right to use great care and attention, and especially 
> in ISRs.
> 
>> but they are very small and limited.
> 
> Many tasks in pre-emptive systems are also small and limited -- for 
> example, one of my designs has a task whose main loop just takes a 
> data-packet from an input queue, computes its CRC and appends it to the 
> packet, and puts the updated packet in an output queue. A handful of 
> source lines.
> 
> I would say that having a pre-emptive system relieves the designer of 
> the great care and attention needed to slice computations into 
> (state-mnachine-driven) "tasks" that execute their computations little 
> by little.

I don't think the CRC computation takes too long to split it in smaller 
and faster steps (state-machine). I think you could write that task 
without a state-machine in superloop architecture:

void task_CRC(void) {
   uint8_t *packet;
   size_t packet_len;
   int err = queue_pop(&packet, &packet_len);
   if (!err) {
     packet[packet_len] = crc(packet, packet_len);
     packet_len++;
     queue_push(packet, packet_len);
   }
}

And here you don't have to think about multithreading issues (race 
condition, sharing resources, ...).

>> Normally the biggest part of the firmware is related to the 
>> application/tasks, not interrupts.
> 
> Except in the aforementioned foreground-background designs.

Even in foreground-background ISRs are limited to critical real-time events.

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