This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Memory fencing problem in pthread cancellation
- From: Carlos O'Donell <carlos at systemhalted dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Jeff Law <law at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 14 Jan 2013 17:51:39 -0500
- Subject: Re: [PATCH] Memory fencing problem in pthread cancellation
- References: <50F46969.1000305@redhat.com> <20130114205045.BE6BF2C094@topped-with-meat.com>
On 01/14/2013 03:50 PM, Roland McGrath wrote:
> I'd like to see comments clarifying what the memory clobber is actually
> accomplishing and why it's necessary. The other introductions of barriers
> that have no comments need comments.
>
Jeff,
I'd suggest something like this:
atomic_write_barrier ();
+ /* At the point at which any thread writes the handle
+ to libgcc_s_handle, the initialization is complete.
+ The writing of libgcc_s_handle is atomic. All other
+ threads reading libgcc_s_handle do so atomically. Any
+ thread that does not execute this function must issue
+ a read barrier to ensure that all of the above has
+ actually completed and that the values of the
+ function pointers are correct. */
libgcc_s_handle = handle;
If your thread did not actually execute the entire
initialization function you must issue a read barrier
to ensure that the CPU does not speculatively move the
load of a function pointer to a point before the
write that sets it to the correct value.
Cheers,
Carlos.