This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] default linux allocator


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]