This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: mt allocator documentation (draft)
On Tue, Feb 03, 2004 at 03:33:56PM +0100, Stefan Olsson wrote:
> >I'd just like to register the fact that I greatly appreciate time
> >taken to ensure that single-threaded performance is still "as good as
> >possible".
> >
> Bad choice of words...
> ...the goal is of course to get as good performance as possible in
> single threaded applications as well - my mind is just so set on multi
> threading right now =)
I meant it as a compliment, not a complaint ;) I meant I was glad to
see that ST had been an important factor.
> You are quite right, when __GTHREADS is undefined we could also remove
> the thread_id var from the block_record struct.
>
> The reason - which at the time when I am writing this I am no longer
> sure that it actually is a reason - was to keep the memory layout the
> same if a ST and a MT program somehow shared containers via some obscure
> IPC mechanism...
> ...not very likely huh? This should probably be changed to save memory.
I agree. I doubt any real-word application would boldly assume that
one could allocate and deallocate STL memory across such a conduit. I
definitely would never rely on it since, clearly, libstdc++ is free to
change its underlying allocation scheme from release to release, so it
would be a compatibility nightmare. :)
--
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company