This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] New functions pthread_[sg]etattr_default_np for default thread attributes
- From: Torvald Riegel <triegel at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 12 Jun 2013 15:49:05 +0200
- Subject: Re: [PATCH v3] New functions pthread_[sg]etattr_default_np for default thread attributes
- References: <20130314122003 dot GY22471 at spoyarek dot pnq dot redhat dot com> <20130314154905 dot ADDDD2C09C at topped-with-meat dot com> <20130315043154 dot GG22471 at spoyarek dot pnq dot redhat dot com> <20130318222239 dot 7A2712C084 at topped-with-meat dot com> <CAAHN_R13bRF0UY_XZ7Rj6tSeSgq8c_0j4bbEH6m9BbGD32EycQ at mail dot gmail dot com> <20130528220730 dot 33C262C06F at topped-with-meat dot com> <20130529065138 dot GF2145 at spoyarek dot pnq dot redhat dot com> <20130529224222 dot 8A87F2C07E at topped-with-meat dot com> <20130606131212 dot GZ13968 at spoyarek dot pnq dot redhat dot com> <20130612000601 dot 54C9F2C06E at topped-with-meat dot com>
On Tue, 2013-06-11 at 17:06 -0700, Roland McGrath wrote:
> > + else
> > + {
> > + lll_lock (__default_pthread_attr_lock, LLL_PRIVATE);
> > + size = __default_pthread_attr.stacksize;
> > + lll_unlock (__default_pthread_attr_lock, LLL_PRIVATE);
> > + }
>
> The lock isn't really needed for a single word fetch that doesn't need to
> be synchronized with anything else.
I agree that locking might not be the most efficient kind of
synchronization, but unless reading the stacksize field will not be
concurrent with other write accesses, we do need some kind of
synchronization / atomic access.
At least, this should be an atomic access with relaxed memory order (ie,
like in C11), or at very least a comment to add that in the future.
Making this an explicitly atomic access will tell users that this is in
fact concurrent code, and it will make sure the compiler handles this
access properly (I believe this isn't a volatile already, or is it?)