Re: [boost] [thread] null_mutex

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-06-12 18:27:56

On Sat, 11 Jun 2005 00:34:08 +0300
"Peter Dimov" <pdimov_at_[hidden]> wrote:

> Let's take a step back. Why would I use the message queue at all in a
> single  threaded program? Its whole purpose is to enable inter-thread
> communication,  right?

How about another step back.  The initial query was about using mutex
and condvar together when null_mutex is defined.  Obviously, if you are
doing this, you are trying to write generic code, which can be used in
both a single and multi threaded environment (otherwise, why even care
about null_mutex).

As one example, I suggested a message queue (there are many other
examples of writing generic code for both single and multi threaded
environments).

If we can agree that writing the same code for single and multi threaded
applications is a good thing (or at least, not a terrible thing), then
we can see the use of null_mutex.

However, in some cases, code will use a condition variable.  We do not
want to disqualify compilation of this code, yet we know that if the
code path is executed in a single threaded environment (or "unlocking"
environment), it would be a "bad thing" to wait.  Thus, I think throwing
an exception is a reasonable course of action if a condition variable is
waited upon with a null_mutex.

Now, taking one step forward from there (and one back from where I was
prior to this email), I should be right where you want me ;-)

Why would I want to use a message queue in a single-threaded
application?  I have several answers, but the biggest one that relates
to this thread (and boost), is code reuse.

Consider an application written to a user level model similar to SVr4
streams.  Each "module" process messages off a message queue.  You can
write all application modules using the same interface.

Also, consider a network application.  If your "reader" modules are
written to put their data on a message queue, then you can easily chain
protocol layers.  If you are using a single thread or multiple threads,
you still use the same code.  If you are multithreaded, another thread
will slurp up the message and process it as soon as it is available (and
the condvar is signalled, and the lock is released).  If you are single
threaded, the message will be processed when the controling code path
decides to process the queue.  In either case, the main processing code
is the same, and the application specific module code is the same,
providing a nice bit of code reuse.  Yes, there is a little overhead in
the message queue, but even in a multithreaded environment, you should
not be putting heavy weight messages on the queue.