Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-08-14 08:00:16


--- In boost_at_y..., "Mark Rodgers" <mark.rodgers_at_c...> wrote:
> From: "Beman Dawes" <bdawes_at_a...>
> >
> > What follows is based on that, except errors are my own.
>
> Thanks Beman for your nice summary. Having been through the
> process of working out how to avoid lost wakeups with events
> several times, and effectively implementing CVs each time as
> a result, I for one welcome the decision to initially just
> support CVs.
>
> It appears that no-one has indicated any fundamental flaws in
> the design, despite a somewhat puzzling "I cannot use this"
> attitude, so I suggest we now move on.
>
> One query I had was in the design for TSS. I guess it's OK
> as a starting point, but ideally I'd like to be able to
> write
>
> boost::thread_specific<int> ti( 3 );
> boost::thread_specific<Foo> tf( "bar", 4.5 );
>
> int j = ti.get();
> tf.get().fubar();
>
> I also don't like "tss". Can we please avoid TLAs for names?

"Pay no attention to the class behind the curtain."

The tss concept is undergoing a lot of work at the moment. What
currently exists is likely to become an implementation detail in the
detail namespace with an easier to use template wrapping it. I'm
puzzling over a few things in this approach, however. Your code
above seems to indicate that the data is automagically allocated for
you the first time you access it and deleted when the thread ends.
This brings up two issues. The first is that the creation requires
default initialization semantics, which will exclude many types from
being (directly) usable as thread specific storage. The second is
that all such data now resides on the heap, while some times thread
specific data is set to the address of a stack object. Both of these
issues can be worked around, but they aren't the easiest/most
efficient solutions.

As for the name... suggest something better. I'm very open to
renaming this one.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk