This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] default linux allocator
- From: Stefan Olsson <stefan at xapa dot se>
- To: Dhruv Matani <dhruvbird at gmx dot net>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>, doko at cs dot tu-berlin dot de, Paolo Carlini <pcarlini at suse dot de>
- Date: Wed, 14 Jul 2004 21:58:47 +0200
- Subject: Re: [v3] default linux allocator
- References: <20040713130810.358e0575.bkoz@redhat.com> <1089816924.4167.7.camel@localhost.localdomain>
Hi Dhruv,
you're correct - there is a chance of a syncronization problem here. It will
never result in a segfault (since all list op's are made on the pointers) but
the remove calculation could try to do funny stuff.
I had on my list (sorry, haven't had much time to do libstdc++ work lately) to
do a test with the atomic functions - I asked Benjamin if one could "trust"
them to always be atleast an integer; and yes that's the case.
There shouldn't be much of a performance penalty for that I hope...
Brgds
/Stefan
Citerar Dhruv Matani <dhruvbird@gmx.net>:
> On Tue, 2004-07-13 at 23:38, Benjamin Kosnik wrote:
> > Yo dudes... this switches this default allocator for linux to
> > mt_allocator. I'd like to try this out on mainline, and then possibly
> > move this to the gcc-3_4-branch after a review of gcc-testresults.
> >
> > Sound like a good idea? Barring objections, I'll do this tomorrow.
>
> No objections, but there is this little thing about the synchronization
> that I had mentioned a few months ago, and it seems to have been
> forgotten!
>
> On line 470:
>
> // Return this block to our list and update counters and
> // owner id as needed.
> --__bin._M_used[__block->_M_thread_id]; //THIS LINE.
>
> __block->_M_next = __bin._M_first[__thread_id];
> __bin._M_first[__thread_id] = __block;
>
> The line marked THIS LINE seems to be faulty to me. What I suspect might
> happen is that because the access to
> __bin._M_used[__block->_M_thread_id] if __block->_M_thread_id !=
> __thread_id is that some other thread might be accessing that variable,
> so the update will not be an atomic one, and it might lead to data
> corruption! So, the suggested way to go would be to use one of the
> __atomic_decrement() functions or something to that effect to ensure
> data consistency. Also, other places in the allocate will have to update
> their variables atomically.
>
>
>
>
> >
> > There also seemed to be interest in making this this default on solaris,
> > and perhaps others. I think these can be separate patches.
> >
> > -benjamin
> --
> -Dhruv Matani.
> http://www.geocities.com/dhruvbird/
>
> As a rule, man is a fool. When it's hot, he wants it cold.
> When it's cold he wants it hot. He always wants what is not.
> -Anon.
>
>
>
--
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.