This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 threads ABI - mtx_t and cnd_t types
- From: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>
- Date: Mon, 6 Oct 2014 13:58:40 -0400
- Subject: Re: C11 threads ABI - mtx_t and cnd_t types
- Authentication-results: sourceware.org; auth=none
- References: <20140727203825 dot GA13146 at brightrain dot aerifal dot cx> <20140831025242 dot GQ12888 at brightrain dot aerifal dot cx> <1412601479 dot 30642 dot 40 dot camel at triegel dot csb>
On Mon, Oct 06, 2014 at 03:17:59PM +0200, Torvald Riegel wrote:
> On Sat, 2014-08-30 at 22:52 -0400, Rich Felker wrote:
> > Another issue I have on the ABI for C11 threads pertains to the types
> > for mtx_t and cnd_t. My understanding, and I agree with this, is that
> > it was already decided to use the same underlying sizes/alignment, and
> > for now representations, as the corresponding POSIX types.
>
> I don't remember a decision being made rather than just people
> expressing their opinion at that time, but maybe I'm wrong.
>
> Anyway, for mtx_t I'm starting to wonder whether a fresh start would
> indeed be better, with some additional room for expanding the lock
> representation to state elsewhere. (That is, mtx_t would at least be
> pointer-sized.)
> The reason for this is the current discussion around the barrier
> semantics. It is slowly moving, and I'm concerned about the Austin
> Group deciding to stick to the less efficient spec for mutexes after a
> long discussion -- which would leave us with larger-than-necessary mtx_t
> while not using the pthread_mutex_t implementation anyway.
I question whether it's "much larger than necessary", especially if
the C committee does not decide to make changes with regard to
orphaned mutexes (see http://austingroupbugs.net/view.php?id=755),
since you need room for a linked list to deal with the tid-reuse
issue. I don't see a way to make a mutex any smaller than what you
have on 32-bit targets now without some hacks like cramming the mutex
type into the upper bits of the lock count or something. If you were
talking about a 50% or 75% size saving, this might be appealing, but I
think at best you'd be looking at shaving off one field, in which case
the expandability is probably worth a lot more than the size savings
(expandability that requires allocation rather sucks, since there's
probably no way an application can deal with failure to create a
mutex, especially for mutexes that are intended to be "static" ones
but which, because C11 lacks static allocation, require call_once and
mtx_init).
Rich