Re: [boost] asio review extended till Dec 30th

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-12-29 13:57:38

Jody Hagins wrote:
> On Thu, 29 Dec 2005 19:38:31 +0200
> "Peter Dimov" <pdimov_at_[hidden]> wrote:
>
>> Jody Hagins wrote:
>>
>>> I'm sure there are many alternatives, but the first to mind (yet
>>> probably undesirable), is to fork a process and use IPC mechanisms
>>> and a very simple protocol in the absence of threading.
>>
>> I'm not sure why is spawning a process and using IPC better than
>> using a  thread. Is adding -lpthread to the command line that much
>> to ask? Where's  the problem?
>
> If that's all it entailed, not it would not be too much to ask.
> However, several libraries in boost force multiprocessor functionality
> on the user if the code is compiled with threaded ability.  A chief
> offender is SmartPointer, made even more heinous because it is used
> all over the place (no problem there -- I use it all over the place too).

I'm not sure what this has to do with the subject. Anyway...

> Thus, if I compile one piece of code for multithreading, now all my
> uses of shared_ptr<> and friends are going to require space for
> mutexes, and worse, they are going to acquire/release locks for every
> operation.  The only way around it is to compile completely without
> threads, which is not what I want either.

... this is not quite correct if you are on a platform where shared_ptr uses 
atomic operations; let's assume for the sake of argument that this is not 
the case. The alternative is obviously to supply another version of 
shared_ptr, one that isn't MT-safe. Interoperability issues aside, this 
would be OK for most people as long as their ST shared pointers never cross 
threads, but it won't solve the problem that you describe unless ALL 
libraries that use shared_ptr ALSO supply two variants of their classes or 
APIs.

This is a maintenance problem that most people would rather avoid; it is not 
a coincidence that compiler vendors are moving away from ST/MT libraries and 
towards a single MT-safe library. The resources that are freed by dropping 
the ST variant are used to improve the performance of the MT library to a 
competitive level.

> One great advantage of C++ is that you can design libraries so that you
> only pay for what you use.  However, several major boost components do
> not adhere to this philosophy, at least not enough.
>
> Thus, IMO, multithread support in some boost libs is just plain wrong.
> Some libs force you to use it all the time or not at all.  Very few
> applications require full MT synchronization primitives for
> everything.

Libraries that have shared state have to protect it somehow. A pure 
value-semantics library like boost::bind can be blissfully unaware of 
threading issues, but not everyone can afford to ignore threads.

> For this library, it even goes beyond that, I'm afraid.  The
> demuxer::run() method always acquires/releases a mutex for each
> operation.

... and this is a problem because..?