Re: [v3] default linux allocator

[Dhruv Matani <dhruvbird at gmx dot net>]

On Thu, 2004-07-15 at 01:28, Stefan Olsson wrote:
> 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.

Right.

> 
> 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.

If that's the case, then it should be fine!

> 
> 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.
> > 
> > 
> > 
-- 
        -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.