Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29086
| 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> |
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
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