[boost] Re: C++0x Wish list (realtime)

From: Daniel Miller (daniel.miller_at_[hidden])
Date: 2002-06-03 11:08:33

William E. Kempf wrote:
[...snip...]

 > I've got a very focused plan for Boost.Threads, which I have
 > to have to get the library into a form that's usable and a good basis.
 > There's some things that are missing for RTOSes that I'm aware of, 
and those
 > *ARE* planned today.  Of course this may not be obvious since they mostly
 > fall under the category I've labeled as "thread parameters" when I've 
talked
 > about this on public lists.  Beyond this there are only two other things
 > brought to my attention that is need by RTOSes, and they are at least
 > somewhat debatable:
 >
 > * Semaphores.  As I've said publicly, I've not counted semaphores out
 > entirely.  So this criticism, though possibly valid, is not evidence that
 > Boost.Threads will (or has) made the wrong decision in this regard,
 > RTOS/embedded systems or no.
 >
 > * Event queues.  I believe this concept to be higher level then the 
scope of
 > Boost.Threads.  I also believe it to not be a thread specific concept (I
 > know others disagree about this, so there may well be something I'm not
 > understanding here).  Despite this I think it an important concept, 
and one
 > that probably should be standardized.  So I don't think it's exclusion
 > should rule out Boost.Threads, RTOS/embedded systems or no.

    Ahhh, we are making some progress regarding realtime embedded systems
education.  But this progress is not yet complete.

    The 2 categories which you mention above are actually 3 separate &
distinct categories in the multithreaded RTOS world (e.g., pSOS, VxWorks).

    1) semaphores (same as your semaphore category above)

    2) nonlossy/queued event delivery (of which POSIX realtime signals is
one presentation, as is pSOS events).  Here delivery is via an
asynchronous call-back function invocation.  For more information
regarding POSIX realtime signals, see:

http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_04.html#tag_02_04_02

    3) FIFO message-queues (of which POSIX System-V ioctl-based message
queues & ACE message-queues are distant overly-embellished cousins and
best ignored for the purpose of this discussion) (of which pSOS
message-queues & VxWorks message-queues are the best examples, except
that instead of having a 4-byte payload, payloads of arbitrary types in
C++ for which an efficient copy-ctor has been defined would be
preferable).  Often for expository purposes, I refer to this
time-honored 2-to-3-decade-old idiom as (multi)producer-(multi)consumer,
emphasizing the fact that M producer threads can post/push to a FIFO
message-queue and N consumer threads can pend/pop from that
message-queue.  The message-queue shall not be limited to being coupled
to any one producer thread.  The message-queue shall not be limited to
being coupled to any one consumer thread.  The one or more consumer
threads which pend on the message-queue do form an implicit thread-pool
whose threads are scheduled by the kernel instead of in user-space.
Here the delivery is via explicit retrieval from an interthread FIFO
queue at one or more well-known points in the control-flow.

    For the written record:
    Contrary to the mistaken belief that message-queues are applicable to
single-threaded applications, the message-queues in #3 are thoroughly
inappropriate for single-threaded applications due to their blocking
nature.  If the sole thread acts as a consumer by pending on an empty
message-queue in a truly single-threaded application, there is no
producer to post/push into that queue, causing a permanent starvation.

    What is applicable to single-threaded software is not the RTOS-style
MT FIFO message-queue, but rather std::queue.  The std::queue already
has all of the semantics which single-threaded applications would need:
queuing without thread-suspension.  On the other hand, the RTOS-style MT
FIFO message-queue has a FIFO queuing behavior like std::queue but it
has thread-suspension which is at best to be avoided in single-threaded
software (e.g., an organization's local coding-conventions rule which
states that only the try-series member-functions are to be invoked for
single-threaded software) and at worst dangerous (lest the permanent
starvation case described above occurs).

    GLOSSARY

    truly single-threaded: Software is "truly single-threaded" if and
only if the embodiment of the software is comprised solely of one thread
in one address-space.
    NOTE: Multiple single-threaded UNIX processes with shared-memory
between them and/or with interprocess thread synchronization between
them specifically do *NOT* satisfy this definition.  Such processes are
a subcategory of multithreaded software requiring
interthread-*inter*addressspace analogous forms of the
more-frequently-encountered interthread-*intra*addressspace
thread-synchronization mechanisms.

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================