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

Groups > comp.arch.embedded > #29092

Re: From cooperative to preemptive scheduler: a real example

Show all headers | View raw

Il 09/01/2020 00:39, Niklas Holsti ha scritto:
> 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:

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

Code clutter. I am worried to forget to add semaphore management to a 
newly added function without noticing the problem (because those bugs 
are very rare to see).


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

void set_var1()
    semaphore_take()
    ...
    semaphore_give()

void set_var2()
    semaphore_take()
    ...
    semaphore_give()

Coding in cooperative scheduler, at first I don't like that code. But 
the big problem is the fear to forget to manage the semaphore when 
accessing some shared variable.


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

Those are right examples, but I think very rare in typical control systems.


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

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