Re: [boost] Re: shared_ptr and BOOST_DISABLE_THREADS

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-04-24 13:00:02

> Bronek Kozicki schrieb:
> > Peter Dimov <pdimov_at_[hidden]> wrote:
> >
> >>Nothing. The implementation of shared_ptr needs a serious redesign WRT
> >>thread safety, which is planned but requires free time on my part,
> >>which is currently in short supply, although I've got some ordered.
> >
> > Are there any chance of using reference linking instead of counter
> > allocated on heap,

Not likely. Reference linking offers little advantage in practice over the
current implementation, even if we drop the fancy custom deleters and weak
pointers to make it look better.

> > or at least some serious optimization (ie. memory
> > pool) in regard to this heap allocation?

Serious memory allocation optimizations (thread specific pools) require a
considerable effort; there's also the problem with thread-specific cleanup
on Win32, which requires either a helper DLL, or would tie shared_ptr to
Boost.Threads.

But depending on your seriousness, you may find the following alternatives
helpful:

0. Make sure that your program is allocation-bound, performance wise.

1. Make sure that your compiler doesn't already have a seriously optimized
malloc. Many do, and the number is growing. If it does, attempts to
"optimize" memory allocations by manually pooling may (and I've seen it
happen) actually cause measurable slowdowns.

2. Replace malloc/global new with dlmalloc (or even a commercial
alternative). The advantage is that you will automatically optimize every
small object allocation in your entire program; remember that every
shared_ptr count allocation has a corresponding object allocation.

3. #define BOOST_SP_USE_QUICK_ALLOCATOR.

From: "Daniel Krügler"
> Reference linking is really great stuff in (single-thread) theory, but
> unfortunatly it seems to have lots of difficulties in mt world.

Right, that too.