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.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3CFB91F0.8000103@tellabs.com...
> 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#t
ag_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.

Ahh... this does shed light into why we have different concepts of what a
message queue is.  However, it doesn't change the fact that I believe this
to be out of scope for Boost.Threads.  At least at this point in time.  If
this concept is critical to your world and you want it standardized I see
three options:

1)  Supply your own pSOS style message queue library for standardization,
possibly (and I'd strongly suggest this) through a Boost effort.

2)  Supply an implementation to me directly for consideration of inclusion
in Boost.Threads (i.e. try to convince me with something real to change my
mind about the scope).

3)  Supply your own threading library as competition for Boost.Threads to
the committee.

I'd suggest trying option 2 first, and if you can't convince me then fall
back on option 1.  Option 3 seems valid (to me at least) only if you think
what Boost.Threads does cover is flawed in some way (and for that I'd
suggest waiting for the 2nd phase to be completed before passing final
judgement).

If you try for option 2, I promise I will evaluate it with an open mind.

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

Not really true.  First, there are asynchronous events that can occur even
in single threaded applications, such as hardware interrupts.  The Windows
platform causes most user input to occur in this manner.  Second, there's
nothing that says such a queue needs to block when retrieving the next
message.  If there's no message pending the call to "next_message" can
simply return with an error that indicates this.  The "dispatch loop" that
handles pending messages can then do some processing that may or may not
cause a message(s) to be posted to the queue.

There are also queues that can be posted to by multiple threads but can be
read from only one thread (multiple producer/single consumer).  This is how
message queues are implemented for Windows.

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

It's possible to encode a message queue that works reliably under both ST
and MT application domains.

Bill Kempf

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]