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

Groups > comp.arch.embedded > #27910

Re: C++ threads versus PThreads for embedded Linux on ARM micro

Show all headers | View raw

On 02/08/18 15:14, upsidedown@downunder.com wrote:
> On Thu, 02 Aug 2018 12:24:49 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 01/08/18 21:11, StateMachineCOM wrote:
>>> On Wednesday, August 1, 2018 at 2:46:08 PM UTC-4,
>>> upsid...@downunder.com wrote:
>>>> It seems Cummings has reinvented the wheel :-). Those principles
>>>> were used already in the 1970's to implement real time systems
>>>> under RSX-11 on PDP-11. Later on these principles were also used on
>>>> real time systems under RMX-80 for 8080 and similar kernels.
>>>
>>> I recommended Cummings's article only because most of the
>>> participants of this discussion seem to be firmly in the "sequential
>>> programming with sharing and blocking" camp. 
>>
>> I can't speak for anyone else in this discussion, but I am in the
>> "Sequential programming with sharing and blocking is /one/ way to handle
>> things, but not the only way.  Indeed, there /is/ no single right way" camp.
>>
>>> For this traditional way
>>> of thinking, the full immersion into the reactive programming
>>> principles might be too big of a shock. Cummings arrives at these
>>> principles by trial-and-error, intuition, and experience. He also
>>> does not call the concepts by strange names like "active object
>>> (actor) pattern" or "reactive programming".
>>
>> He also gets something /seriously/ wrong.  His model of "a typical
>> thread" on page 4 is completely incorrect - and his whole argument
>> breaks down because of that.
> 
> The method just describes how real time (i.e. with upper limit for
> execution time) is usually done. Most (often over 99 %) of the time
> each thread/task/process is in the wait state waiting for an event,
> (such as message queue, event flag etc. depending of implementation).

Most of the time, threads (other than an idle or background thread) will
be waiting, yes.  But it is completely wrong to suggest that they will
necessarily be waiting at the outside of the thread function as
suggested by his structure.

> When an external event, such as serial line or clock interrupt occurs,
> some task is activated, possibly sending messages etc. to other task.
> When done, each task returns to the wait state. Usually there are only
> one runnable task at a time. If more tasks become runnable at the same
> time, they are executed in priority order. Very nice and clean.

Yes, I understand how threading works.  I also understand that it is
/not/ a requirement that waiting threads are sitting in their outer loop
waiting for a new message - they can make blocking calls at any point in
their execution.  What the author calls a "typical thread" is only one
possible thread structure, and is certainly not a typical one.


> 
>>
>> /Some/ threads are event driven services - they wait for messages coming
>> in, process them, and then go back to waiting for another message.  This
>> is basically a cooperative multi-tasking system - the sort of thing we
>> had to use before multi-threading and multi-tasking OS's were suitable
>> for small embedded systems.  (It's also what we had in Windows for long
>> /after/ every other "big" OS was multi-tasking.)
> 
> Windows NT 3.5 and later on was a full blown priority based
> multitasking system with close resemblance to RSX-11 and VMS.

I know.  But in the days of Win 3.x, most "big" OS's were multi-tasking
- Windows (and, perhaps, MacOS - I am not as familiar with that) was the
exception.  Other systems were running *nix variants, VMS, or other
multi-tasking OS's.  Windows did not catch up until NT.

> 
> Processor capabilities is no excuse for not having priority based
> multitasking. In the 1970/80's  practically every company using 8
> bitters had their own RT kernels. The Intel RMX-80 for 8080/85 might
> be familiar to some in this NG.

I disagree.  Multi-tasking OS's require a certain overhead of ram and
processing power.  If you only really need to do one thing, or if the
requirements can be stacked in a simple linear form (background task,
with layers of clearly prioritised interrupts on top) then such systems
are much more efficient use of resources.  And a cooperative
multi-tasking system fills the middle ground between features and
efficiency, if it is good enough for the requirements.

Certainly you /can/ make a multitasking RTOS for even the smallest of
processors.  That does not make it a sensible choice.

>   
>>
>> Threads like that can be a very useful structure, and can be very
>> efficient ways to model certain types of problem.  They are excellent
>> for handling user interaction, and are thus very popular for the main
>> thread in gui programs on desktops.  
> 
> I  usually put the (l)user interface in the null task (lowest priority
> task), so whatever the user does, it doesn't affect the really
> important parts of the system.

That is often a good idea!

> 
>> They are also marvellous as pretty
>> much the only thread (baring perhaps timers and interrupts) on many
>> embedded systems - in particular, you know that when the thread is in
>> the "Process message 1" part, it can't be in the "Process message 2"
>> part, and thus you can avoid a great deal of locking or other
>> synchronisation.
>>
>> But a key point is that a thread like that should avoid (or at least
>> minimise) any blocking or locking, and usually it should avoid any code
>> that takes a long time to run (possibly by breaking it up, using a state
>> machine).
> 
> Think about the various cases as interrupt service routines. Compare
> this with a multiline serial card with a single interrupt. You first
> determine which subsystem caused the interrupt and handle it
> accordingly. Of cause, the ISR should be then handled quickly as
> should the various message processing. The return from interrupt is
> then comparable to go to the loop wait state.
> 

Yes, that is clear - and like the ISR, such event-driven threads should
process the messages quickly or hand them off to other threads when
long-running work is needed.  These other threads, however, do /not/
have to be structured as event-driven with message queues as their point
of entry.

>>
>>
>> Other threads can have completely different structures.  In particular,
>> they /can/ have blocking operations because it is fine for them to block
>> - the blocking operations are part of the normal flow of the sequential
>> processes that are clear in the code and easy to track.  
> 
> If you need complicated sequential processing, such as in the (l)user
> interface, put it into the null task.
> 
>> That might mean
>> you have more threads than you would otherwise need, and a corresponding
>> loss in overall system efficiency, but that is the price you pay for
>> better modularisation and clearer code flow.  And you can have a range
>> of different types of synchronisation - using whatever makes the best
>> balance between efficiency, clear coding, and provably correct
>> synchronisation (i.e., you can be absolutely sure you have no deadlocks,
>> livelocks, etc.).
>>
>>
>> The "problem" described on pages 5-6 of the article stem from two errors
>> by the author.  
> 
> Yes, this is "self inflicted headache" (hangover) :-=
> 
>> One is to mix up the structures and responsibilities of
>> the threads - he has thread A being an event-driven service thread that
>> uses significant blocking in part of its processing.  The second problem
>> is that he has no clear picture of the control flow and the interaction
>> between threads, resulting in circular dependencies.  If you want an
>> efficient (and, for hard real time, correct) multi-threaded system you
>> have to know what your threads are, how they communicate, who waits for
>> what, and what deadlines you have - and arrange things so that you don't
>> have unnecessary waits.
>>
>> The variety of incorrect "solutions" then given are clearly problematic,
>> as he says - but he misses the obvious one which is to restructure the
>> threading and communication.  For example, a better solution might be to
>> introduce a new thread C whose job is to handle the work currently done
>> in thread A in response to message 1.  Thread A's handling of message 1
>> thus becomes "trigger thread C", and all the work - including blocking
>> if that is the most convenient solution - is done in thread C.  Thread A
>> can go back to handling events.  But for some reason, the author (and
>> many other authors on such topics, IME) does not think of adding another
>> thread.
>>
>> He also discusses the idea of the call to thread B being essentially
>> non-blocking, and with B sending its response as a message back to A.
>> But for some reason he says that should be a different message queue
> 
> I also wondered why.
> 
>>
>> that A would block on, giving the same problem but with a far more
>> complex structure - I can't see why anyone would suggest that as a
>> possible solution.  The response from B should either go into the main
>> event queue for A (perhaps this queue would need to be prioritised), or
>> (if the OS has the support) it could go in a separate queue with A
>> waiting for /either/ queue, maybe with a priority mechanism.
> 
> What is the point of having a queue priority, if there is already a
> state machine for Msg1 processing ?
> 

You may want the reply from B to be handled quickly, at higher priority
than ordinary messages coming in to A.  If so, you would either have a
second queue that has a higher priority (but wait on both), or use a
priority queue as your main event queue into A.  Having a single
priority queue is the most flexible as long as all your messages will
work with it.

>>
>> He is right in noting the dangers of using callbacks as a solution, as
>> they are logically in the domain of one thread but executed in the
>> context of another thread. 
> 
> Callback from some system service makes sense (i.e. translated
> interrupts), but I have seldom seen callbacks from one application to
> an other.

No one talked about callbacks between "applications" (do you mean
"processes" here?).

> 
>> The answer here is that callbacks need to be
>> short, deterministic, thread-safe and do as little as possible.  Still,
>> many of the potential problems he sees are due to poorly structured
>> threading and coding.  For example, he says:
>>
>> "Additional challenges can arise if, for example, Thread A is in the
>> middle of processing a large collection of data when the callback
>> executes, and if the response from B includes an update to a portion of
>> that collection of data."
>>
>> Proper structuring of responsibilities and encapsulation of the data and
>> code acting on it would mean that is not allowed - or that it can be
>> done in such a simple atomic way that there is no problem.
>>
>>
>> Really, most or all of the problems he sees could be solved by saying
>> "/Design/ your multi-threaded system carefully, and don't be afraid of
>> splitting tasks into new threads" rather coding first and thinking
>> later, programming by trial and error, and using hacks instead of
>> re-structuring as needed.
> 
> I use to limit the number of different tasks to 10, so that I can keep
> track of them with my fingers. Using more than that, would also
> require me to use my toes and my colleges might not appreciate, if I
> took off my socks  :-)
> 

There is a lot of sense in limiting a system - it should be as simple as
possible, but no simpler.  An artificial limit is not helpful, however,
and encourages the kind of restricted "solutions" suggested by the
author of that paper.  If adding a new thread simplifies the structure
of your program, then use it - even if you have to take your socks off.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

C++ threads versus PThreads for embedded Linux on ARM micro "gp.kiwi@gmail.com" <graeme.prentice@gmail.com> - 2018-07-20 04:01 -0700
  Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-07-20 20:19 +0200
    Re: C++ threads versus PThreads for embedded Linux on ARM micro graeme.prentice@gmail.com - 2018-07-20 15:54 -0700
      Re: C++ threads versus PThreads for embedded Linux on ARM micro Paul Rubin <no.email@nospam.invalid> - 2018-07-20 18:27 -0700
        Re: C++ threads versus PThreads for embedded Linux on ARM micro graeme.prentice@gmail.com - 2018-07-20 23:58 -0700
          Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-07-21 14:32 +0200
            Re: C++ threads versus PThreads for embedded Linux on ARM micro mac <acolvin@efunct.com> - 2018-07-26 19:37 +0000
          Re: C++ threads versus PThreads for embedded Linux on ARM micro Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-07-21 21:48 +0300
          Re: C++ threads versus PThreads for embedded Linux on ARM micro Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-07-23 09:58 -0700
  Re: C++ threads versus PThreads for embedded Linux on ARM micro Les Cargill <lcargill99@comcast.com> - 2018-07-22 13:15 -0500
  Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-07-27 08:51 -0700
    Re: C++ threads versus PThreads for embedded Linux on ARM micro "gp.kiwi@gmail.com" <graeme.prentice@gmail.com> - 2018-07-27 14:53 -0700
      Re: C++ threads versus PThreads for embedded Linux on ARM micro Paul Rubin <no.email@nospam.invalid> - 2018-07-27 15:23 -0700
      Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-07-30 09:08 -0700
      Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-07-31 09:21 +0200
    Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-07-31 09:13 +0200
      Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-07-31 15:16 -0700
        Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-01 07:53 +0200
        Re: C++ threads versus PThreads for embedded Linux on ARM micro pozz <pozzugno@gmail.com> - 2018-08-01 15:49 +0200
        Re: C++ threads versus PThreads for embedded Linux on ARM micro upsidedown@downunder.com - 2018-08-01 21:47 +0300
          Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-08-01 12:11 -0700
            Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-01 20:23 +0100
            Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 12:24 +0200
              Re: C++ threads versus PThreads for embedded Linux on ARM micro upsidedown@downunder.com - 2018-08-02 16:14 +0300
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 16:43 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-08-02 09:12 -0700
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-02 18:13 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 23:05 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-08-02 14:22 -0700
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-08-03 10:14 +0300
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-03 10:22 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-02 23:48 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro upsidedown@downunder.com - 2018-08-02 19:56 +0300
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-02 18:14 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 23:12 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-02 23:52 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-03 10:28 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-03 11:21 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-03 13:51 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro upsidedown@downunder.com - 2018-08-03 09:11 +0300
                Re: C++ threads versus PThreads for embedded Linux on ARM micro George Neuner <gneuner2@comcast.net> - 2018-08-04 03:00 -0400
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Robert Wessel <robertwessel2@yahoo.com> - 2018-08-02 12:23 -0500
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 23:13 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro George Neuner <gneuner2@comcast.net> - 2018-08-04 03:08 -0400
              Re: C++ threads versus PThreads for embedded Linux on ARM micro Robert Wessel <robertwessel2@yahoo.com> - 2018-08-02 12:23 -0500
              Re: C++ threads versus PThreads for embedded Linux on ARM micro George Neuner <gneuner2@comcast.net> - 2018-08-02 14:15 -0400
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-02 19:21 +0100
                Re: C++ threads versus PThreads for embedded Linux on ARM micro David Brown <david.brown@hesbynett.no> - 2018-08-02 23:18 +0200
                Re: C++ threads versus PThreads for embedded Linux on ARM micro Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-08-03 00:02 +0100
          Re: C++ threads versus PThreads for embedded Linux on ARM micro StateMachineCOM <statemachineguru@gmail.com> - 2018-08-01 12:28 -0700

csiph-web