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: [PATCH][RFC] Remove volatile from data members in libstdc++


It's been a long time ...

Looking at rope, the volatile declarations in front of __tmp make no
sense to me, though I probably put them there.

The ones in front of _M_ref_count are trickier.  These are accessed
outside a lock in some cases.  (The lock may not even exist if atomic
updates are used.)  I think there is currently no way to do this
correctly.  The accesses should use some sort of "load atomically w.r.t.
threads and do not cache" primitive, but I don't think we currently have
that.  (There is an effort to fix this in the C++ standards committee,
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html)
Given that volatile generally has that effect, my inclination would be
to leave it for now.

In my view, the real problem here is that we have to cheat, because
reference counting with locks is too slow.  But we don't have sufficient
primitives to cheat correctly.

I don't think I directly wrote either of the allocators under discussion
here.  I'm not sure there's a good reason for the volatile declarations
in pool_allocator, and it may be safe to remove them.  The question is
whether the free_list entries are ever updated without a lock, relying
on the atomicity of the underlying hardware instructions.  It looks to
me like the answer is probably no, but I cannot reconstruct the original
reason for the declarations.  (Again, even if they are updated without a
lock, "volatile" isn't the right tool.  But we don't have the right
tool.

For mt_allocator.h, I would definitely try to contact the original
authors, at least if this is viewed as important.

My real inclination would be to remove the volatile declarations for
__tmp in the rope implementation, and leave the rest of this until it
becomes clear what C++0X has to say about atomic operations, at which
point a lot of this will have to be looked at carefully.

Hans

> -----Original Message-----
> From: Paolo Carlini [mailto:pcarlini@suse.de] 
> Sent: Monday, July 10, 2006 5:21 AM
> To: Richard Guenther
> Cc: gcc-patches@gcc.gnu.org; libstdc++@gcc.gnu.org; Boehm, Hans
> Subject: Re: [PATCH][RFC] Remove volatile from data members 
> in libstdc++
> 
> Richard Guenther wrote:
> 
> >Of course the only semantics that matter are those specified in the 
> >standard, and those are not useful in the context of locking or 
> >serialization.
> >  
> >
> To summarize, we have no idea why the (respected, would be 
> Hans Boehm, I
> guess) author of that code decided to add the volatiles... 
> I'd like to understand the issue a little better before going ahead...
> 
> I'm adding Hans Boehm in CC, maybe he want to comment... 
> Thanks in advance, in case.
> 
> Paolo.
> 


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