Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-12 10:33:31

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.

struct page{
  user_ptr ptr[0x10000];
};

page *pages[0x10000];

operator*(){
  size_t pagenr=this->index & 0xffff0000];
  page *p=pages[pagenr];
  if(!p) p=pages[pagenr]=new page;
  return p[this->index & 0xffff];
}

if 64K*sizeof(user_ptr) per page is too much that can be reduced by setting a 
reasonable maximum below 4 billion or by using a third indirection.

could you ellaborate on your case that can't accept reallocation?
I can't think of a case. as long as there is an allocation (and there is one 
in the current implementation, too) there's a mutex lock and no guarantee on 
the time it takes to return anyway.