This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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][BZ 18743] PowerPC: Fix a race condition when eliding a lock


On Fri, 2015-07-31 at 12:14 -0300, Tulio Magno Quites Machado Filho
wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
> 
> > On 07/30/2015 12:48 PM, Tulio Magno Quites Machado Filho wrote:
> >> Note: this patch is updating the NEWS section of glibc 2.22 because that's the
> >> only one available right now.  Whether this patch will end up in glibc 2.23
> >> or 2.22 has to be defined.
> >
> > No for 2.22. Please work on 2.23.
> 
> Ack.
> 
> > You will need to describe in much more detail exactly what synchronization
> > you are using to ensure that this is race-free now.
> 
> In fact, I'm using the same mechanism already available.  I'm just adding
> another step inside the critical path.
> But I'll improve my commit message and the comments in the code.
> 
> > If there is any synchronization going on with HTM we need a way to describe
> > that synchronization and document the concurrency aspect of the change. It
> > is the only way we'll remember what we did when we come back to look at this
> > code in 1, 2, 5, 10 years.
> 
> Agreed.
> 

I also think using relaxed-MO atomic operations inside the transactions
is better for accesses to data that is accessed concurrently outside of
transactions too.  The HW txn will ensure atomicity and thus there's no
difference no matter what code the compiler generates *inside* of a
transaction (it shouldn't generally move past txn boundaries, of
course).  Nonetheless, using atomic accesses will improve clarity of the
code.


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