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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 12 Jun 2013 09:42:02 +0530
- 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, Jun 11, 2013 at 05:06:01PM -0700, Roland McGrath wrote:
> > + {
> > + /* Is this the best idea? On NUMA machines this could mean
> > + accessing far-away memory. */
> > + iattr = &__default_pthread_attr;
> > + lll_lock (__default_pthread_attr_lock, LLL_PRIVATE);
> > + }
>
> Taking the lock around so much code is very scary. Even if you have no
> bugs leading to error paths that fail to unlock, it is unnecessary
> serialization. Except for the cpuset pointer, it would be trivial just to
> make a local stack copy of the global while locked, and then use that.
I didn't think too much of this in terms of serialization because the
only programs that will actually keep writing to the default
attributes would suffer from lock contention. However, I realize now
that there could be contention for reading default values too, and
also serialization between two threads on creation, which is bad.
I'll make a local deep copy on stack. Allocating a copy of the cpuset
would definitely be better than serializing thread creation. Maybe I
could update the code in 2.19 to use read/write locks so that only
writing causes contention. I've wondered if an RCU-type mechanism
would be useful in glibc - maybe this is one such case.
> I have to run now and I haven't reviewed the test case yet.
Thanks for the review. I hope to have an updated version ready by the
time you wake up. My test case had a few minor points that I realized
later that I didn't like (mostly related to error reporting in the
RETURN_IF_FAIL macro), so I'll be updating that too.
Siddhesh