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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-29 14:26:23

On Thu, 29 Dec 2005 20:57:38 +0200
"Peter Dimov" <pdimov_at_[hidden]> wrote:

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

It is relevant because asio currently requires a multithread build, or
it will not compile.  Thus, it forces me to set multithreading in my
compilations, which in turn means that all my code (or an other boost
code) that uses Boost.SmartPointer or other boost libs that do the same
thing, is going to be forced to go through multithreaded primitives and
other MT safe code.

Thus, to use asio, I'm being forced to pay for lots of multithreaded
stuff that I'm not necessarily using.

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

Right.  ACE uses sunchromization policies, which solves the payment
problem, but it does mean that other classes either need to specify
their use, or also allow the synch policy in their interface.

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

I can certainly understand that.  However, MT-safe is different than
what I'm talking about.  Some stuff is MT-safe without synchronization
primitives.

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

I understand.  However, simply by using some libs I am now forced to pay
attention, whether I want to or not.

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

Because every time through the loop, you pay for the synchronization,
when it is not needed.  The only reason for its existence is so that
multiple threads can call demuxer::run() at the same time.  Aside from
implementation questions brought up earlier about calling os demux hooks
from multiple threads, this is extremely undesirable in the more common
case where a single thread calls run().

Maybe I'm not being very clear, or maybe you don't think it is bad to
uselessly call to synchronization primitives.