Re: [Boost-build] Liking to pthreads

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-19 01:51:24

On Tuesday 19 September 2006 02:31, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> >> >> There's far too much code now that's portable
> >> >> only between Linux distros.
> >> >>
> >> >> I really think you should ask around on HPUX, AIX and *BSD groups,
> >> >
> >> > I'd go as far as say that if on any system, multi-threaded library
> >> > can't be used by single-threaded application, it a bug.
> >>
> >> I think that's presumptuous.  It's easy to imagine an embedded system
> >> where making that usage possible would induce overheads in the ST
> >> application that the designers wanted to avoid.
> >
> > For example?
>
> Simple: errno always refers to something in TLS in a MT build, so
> there's an extra level of indirection to access it.

Ok, noted as point (1).

> > And which of operating systems above are embedded?
>
> Any of them, potentially.  Linux can be embedded.

Embedded Linux is basically Linux running on "embedded" system, whatever it 
is. There are not many differences.

> >> > It essentially means that all applications must be multi-threaded.
> >>
> >> No, it means that any application with a multithreaded component must
> >> be entirely built with multithreading enabled.
> >
> > On UNIX systems, it is not typical to have -st and -mt versions of
> > libraries.
>
> When an issue of correctness is concerned, I don't care what the
> typical case is.  We should be safe by default and only optimize when
> we know it's OK.
>
> >> >> and consider Windows, before making this assumption.
> >> >>
> >> >> In any case, the cost is low, providing you have a heap manager that
> >> >> isn't poor.
> >> >
> >> > The cost is the cost of enabling mutexes all over the place.
> >>
> >> Where?
> >
> > Anywhere where a code uses _REENTRANT to decide if we're building mt-
> > code and enables locking. boost::shared_ptr would be an obvious example
> > (though IIRC it does not use mutexes on x86 now, it used to).
>
> And that is exactly an example of the potential problem.  If you pass
> shared_ptr<T> across Boost.Python module boundaries and one is
> compiled with MT enabled, you have an ABI change.
>
> I don't understand why you're so attached to avoiding mutexes in the
> default case.  It's Boost.Python; we're typically getting a 1000x
> speedup from using C++ instead of Python anyway, and there's a way to
> avoid the extra overhead if you're really serious about it

In point (1) above you argue that overhead of accessing errno via TLS can be 
unacceptable. Now you're saying that the overhead of using mutexes is fine, 
and I think mutexes overhead is much larger.

Note also that we're not talking about Boost.Python -- we're talking about 
requiring all code that links to Python to be <threading>multi

> (e.g. <undef>_REENTRANT or better, -<threading>multi).  My users can
> tolerate that.  They can't tolerate hard-to-debug ABI conflicts.

Well, I can modify python.jam, so that on all Unix-but-not-Linux platform, if 
you try to use python target when threading != multi, you'll get the 
following error:

    error: the Python library on your system is multithreaded, but you
    seem to be using it from a single-threaded program. It is possible
    that on your system single- and multi- threaded libraries are not link
    compatible, and the resulting application will not work.
    You can either make all your application multi-threaded, or supress
     this error by referring to python as /python//python/<threading>multi

Would that be OK from your point of view?

- Volodya
 

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2