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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Wed, 12 Jun 2013 15:56:06 +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> <20130612041202 dot GR8010 at spoyarek dot pnq dot redhat dot com>
On Wed, 2013-06-12 at 09:42 +0530, Siddhesh Poyarekar wrote:
> 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.
Note that if you use a traditional read/write lock, you will get
contention too because even acquiring a read lock will modify the lock
itself. The read/write lock would not serialize readers, but with short
critical sections, the contention between the readers (when they
acquire/release the read lock) is a bigger problem than just serialized
read accesses.
> I've wondered if an RCU-type mechanism
> would be useful in glibc - maybe this is one such case.
RCU might be one option, but it's probably easier in this case to go for
a snapshot/lock combination: The lock is acquired for every
modification of the state (or as a fallback), and snapshots of the state
are taken optimistically with potential retrying if the state was
modified concurrently.