|
Boost : |
Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-12 10:36:33
Am Tuesday 12 January 2010 16:33:31 schrieben Sie:
> Am Tuesday 12 January 2010 15:17:05 schrieb Vicente Botet Escriba:
> > > thread_specific_ptr operator*:
> > > one branch to make sure the vector is large enough(a new
> > > thread_specific_ptr might have been created by another thread), one
> > > indirection.
> > > constant-time average, linear to vector if reallocation is necessary.
> > > but that can only happen when a new thread_specific_ptr was created.
> > >
> > > I think the branch also could be avoided with some effort and a second
> > > indirection(using pages to avoid reallocating and making sure the page
> > > exists in each thread on thread_specific_ptr construction) but to me
> > > the branch is acceptable.
> >
> > For me it is unacceptable to use reallocation of the vector on the
> > operator*. More, any non-constant time operator* don't satisfy my
> > requirements for some specific contexts.
>
> I'd prefer reallocation, but reallocation can be avoided using pages at the
> cost of a second or third indirection.
plus, as I've said it could be possible to do the work on construction of a
thread_specific_ptr for all threads so there is no branch in operator*.
however, that depends on if the boost thread API can be used together with
other thread APIs, because then the pages must be initialized on start of a
new thread. so only boost threads could access thread_specific_ptrs,
accessing a thread_specific_ptr from a natively created thread would fail.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk