Re: [boost] Re: Boost.Threads - Final Design Decisions

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-22 12:51:03

Alexander Terekhov wrote:
> 
> >    I'm going to try again. I have no dispute with your
> > assertions. I have no dispute with the need for TLS and adoption.
> > However, the need does not exist when creating a brand new
> > boost supported program using the threads library.
> 
> IMHO, the need (for TLS/TSD) DOES exist even when creating
> a brand new boost supported program using the threads library.

        Hang on. I think my statement was so abbreviated as to
be misinterpreted. What I should have said was: you may need
TLS/TSD in a 'pure' boost threads system, but you do NOT
need any special library functions to get it.

        For example, to create TLS, just say 'malloc'.
To create TDS, just say 'malloc'. In the first case,
don't tell anyone the pointer you get back. In the second,
tell threads you want to share with.

        You don't need special functions to allocate
TLS/TDS, all you need is to pass pointers (or not pass them)
as required.

> IMHO TSD/TLS/TSS/.. is simply a relatively inexpensive
> mechanism to provide a function with some context
> (thread-specific) state info w/o having to do so using
> thread stack which is not free as well (especially taking
> into account the cost of propagation to the next
> function(s) and next function(s),...).

        The cost of propagation using pointers is guaranteed
to be smaller for a well designed sharing/no sharing mechanism
than any general pupose function call. The argument is
spurious. The proof is trivial: you can share by passing
a single pointer at construction time to a data structure
which provides key to pointer mapping just as the POSIX
function does. So you can manually do at least as well
as, say, the POSIX mechanism, and you can probably do much
better.

        The exception is legacy code, where you would
have to destabilise the code by passing extra arguments
down chains of function calls: that's the correct
and most efficient technique, since it doesn't involve
implicit coupling, and is enough to implement what
TLS/TDS functions provide, but it may be expensive
in that it destabilises an old program which is
working correctly, but perhaps now needs to be ported.

        We need to note that with the C++ threads,
we already have a suitable thread _object_, namely
the thread_func which is used to run the thread.
That didn't exist in the C API, and there was no
visible thread object either (just a handle).
So for C, there really was a need for a library
function. In C++ there is not, we have an object
to put data in already.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net