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

Groups > comp.arch.embedded > #29082

Re: From cooperative to preemptive scheduler: a real example

Show all headers | View raw

On 2020-01-08 0:51, pozz wrote:
> Il 07/01/2020 15:51, Don Y ha scritto:
>> On 1/7/2020 2:11 AM, pozz wrote:
>>> Il 07/01/2020 03:37, Don Y ha scritto:
>>>> On 1/6/2020 6:08 PM, pozz wrote:
>>>>
>>>> [ 8< ]
>>>>
>>>>> My impression is that a very simple code is cluttered with 
>>>>> synchronization things that decrease readability and 
>>>>> maintainability and increase complexity. Why? Just to use preemption?
>>>>
>>>> The "clutter" is introduced because your "problem" inherently involves
>>>> conflict; you're allowing two competing uses for a single resource.
>>>
>>> Howevere the shared resource complexity is present only when 
>>> preemption is used.
>>
>> Because it doesn't work right in the nonpreempt case!  :>
> 
> Why do you say this? This application can work flowlessy even with 
> cooperative multitasking.

Only if you have a pre-empting serial-line interrupt handler and a 
"serial_rx" function that interacts properly with that interrupt 
handler, although the two share data (the input queue) and the latter 
can pre-empt the former when interrupts are enabled.

The design of that interrupt handler and the "serial_rx" function will 
exhibit some of the "clutter" you are complaining about.

    [snip]

> It's a matter of coding style. I don't have any 
> experience in multi-tasking systems so I am worried about them. There's 
> a learning curve for coding tasks in a preemptive environment that it 
> appears to me a waste of time if I'm able to reach the same goal with a 
> completeley different approach that is much more friendly to me.

If the system didn't supply that interrupt handler and the associated 
"serial_rx" function, the "friendly" approach would not reach the same 
goal as the pre-emptive approach.

> Anyway I'd like to learn a little of the other approach. This is the 
> reason of my posts.

In addition to the CSP approach -- which is a bit theoretical, as few 
programming languages support it directly -- you could look at how Ada 
does multi-tasking, by looking at the slides for the book "Real-Time 
Systems and Programming Languages (Fourth Edition) Ada 2005, Real-Time 
Java and C/Real-Time POSIX", at

https://www.cs.york.ac.uk/rts/books/RTSBookFourthEdition.html

(the book itself is not free, unfortunately).

>> And, if they *do* need to be aware of each other, make their interactions
>> very visible and restricted to a small set of operations.
> 
> In my very simple application (display showing a message) there is a 
> sharing resource that can't be avoided (at least to me). Imagine if many 
> variables would be set through the serial line: a semaphore everytime 
> both tasks need to access those variables!

What is your concern with that? You only need one semaphore to provide 
mutual exclusion between two tasks, not a separate semaphore for each 
shared variable.

Are you worried about the processor time for the semaphore operations? 
or the code clutter?

If you have many variables, shared in that way, you probably have some 
way of identifying a particular variable by a run-time value, such as an 
enumeration or a string name, and then you can write a single function 
that accesses any one variable when given the identifier of that 
variable as a parameter, and you can encapsulate the take/give of the 
semaphore within that function.

In such cases, you should also consider carefully /when/ a task should 
accept a change in a variable. It is often the case that failures or bad 
behaviour can result if a task uses a variable, X say, in two places, 
but the value of X changes unexpectedly between the first use and the 
second use, because there is a "yield" or pre-emption between the uses. 
Then it is better for the task to take a local copy of X, at a suitable 
point in its execution, and use that local copy subsequently, until it 
is time to refresh the local copy. Using the local copy of course does 
not need mutex protection.

> So the worst-case superloop duration is the sum of worst-case > durations of each task, plus worst-case duration of interrupts.
 > If tasks are coded as non-blocking (state-machine), this worst-case
 > duration could be very small and real-time requirements can be
 > respected.

You might try coding an FFT or Quicksort or other complex algorithm as a 
state machine, with a variable overall length of the input and output 
arrays, and then compare the "clutter" of those state machines with the 
clutter of pre-emptive coding.

> Again, in my approach every task are *non-blocking*,

(Just a note that this use of the term "blocking" does not conform with 
its normal use in task scheduling, where a task "blocks" when it 
suspends itself to wait for some event that has not yet happened, or 
when it cannot execute because a higher-priority task is executing. Such 
"blocked" tasks are not running and are not using processor time. A task 
that just runs and computes for say 60 seconds is not "blocking" in the 
normal sense of the word.)

> so they take 
> 100us-1ms maximum at each loop. If I have 10 tasks, superloop duration 
> could be estimated in 10ms maximum. If the most critical real-time 
> requirement is 100ms or more, cooperative multitasking is ok.

Yes, everything depends on the execution times and the required response 
times. If cooperative works, without excessively cluttered state 
machines, and you are not worried about significant long-term evolution 
of the SW, it may be a defensible approach.

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