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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-18 19:35:21

William Kempf wrote:
> 
> We're nearing the date slotted for submission of Boost.Threads, but there
> are still a couple of design issues that I need to work out.  So, I'm coming
> here one final time for opinions.  I *think* I know what to do in each case,
> but I want to see if I'm missing something.
> 
> The first is the thread specific storage concept.  My final design is the
> following:
> 
> template <typename T>
> class thread_specific_ptr : private noncopyable
> {
> public:
>     thread_specific_ptr();
> 
>     T* get() const;
>     T* operator->() const;
>     T& operator*() const;
>     T* release();
>     void reset(T* p=0);
> };
> 
> This is similar to std::auto_ptr<> in it's interface, though the type is
> non-copyable.  When a thread is created it's thread specific instance is
> initialized to 0, so the first time get() is called it will return 0.  For
> this reason calling operator->() and operator*() may be dangerous.  Given
> this and the fact that these operations are expensive enough that most
> usages will probably use get() instead and cache the value, I'm wondering if
> the smart pointer operations should even be included?

        Yes. The reason is: templates depend on syntax. When using
templates, you don't always have the choice of first calling get(),
then using the temporary. For a similar reason, it makes sense to
allow simple comprehensible code to be written, even if it isn't
the most efficient, because often efficiency is irrelevant
and maintainability is a high priority.

        []

> Comments?

        Well specified. As to the new join semantics:
I have some concern that at one place you argue for the
strongest semantics, whereas elsewhere you support
thread local storage -- which is a hack -- and consider
adopting threads. If you adopt threads, and use TLS,
then there could well be a 'backwards compatibility
reason' for several threads to join another -- for
example, you said yourself you have done this.
Now suppose you had to adopt those threads -- i.e. you didn't
have further control over the thread func than 'porting',
then you might have to allow several threads to join another.

        Ideally, you could separate 'hacks' like TLS
and adoption, from 'top level pure boost threads',
with which new well principled designs could be constructed.
[Is there a way to do this using, for example, an extra
namespace?]

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