This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C11 threads ABI - mtx_t and cnd_t types


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]