Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Jul 2014 01:26:09 +0200
From: Jens Gustedt <>
Subject: Re: C11 threads

Am Freitag, den 25.07.2014, 18:19 -0400 schrieb Rich Felker:
> Since glibc is going that way, I think we should keep the type sizes
> the same but leave it explicitly undefined to mix calls to C11 and
> POSIX functions on the same synchronization objects.

yes, defitively. Not even for the synchronization functions, basically
none from pthread and C11 thread should be mixed, I think. I thought
of figuring out a way to make this even a link error.

> Could you elaborate? Perhaps we're thinking of different things.


The C11 specification is so bad, that some of the functions don't even
have a semantic description of what they are supposed to achieve. E.g
tss_t completely lacks a description of what a destructor is, what
the "iterations" in TSS_DTOR_ITERATIONS describe etc. Parts of it are
or will be adressed TC, but there is much more. I wrote my findings up

> One aspect is that all POSIX synchronization functions are full
> barriers, whereas presumably the C11 ones are proper acquire/release
> barriers as appropriate for the operation being performed.

That is probably the intention. But e.g mtx_lock is only required to
synchronize with calls to mtx_unlock, not with other calls to mtx_lock
or similar. The term "lock" isn't even defined.

> Another is Austin Group issue #755, which I'm hoping the WG14 will not
> rule the same way on. The Austin Group's resolution for POSIX mutexes
> makes recursive and error-checking mutexes very expensive and requires
> threads to maintain a record of all such mutexes they own. I have not
> yet implemented this in musl but I plan to do so soon (BTW this needs
> to be added to the roadmap).

I am not sure that I completely understand what this is about. But in
any case, C threads don't have error checking :)

> > The advantages that I see that this doesn't need all that attr stuff
> > and has no concept of cancellation.
> Cancellation is rather irrelevant to the synchronization primitives.
> Obviously C11's lack of cancellation makes C11 threads much easier to
> implement if you're not also doing POSIX threads, but if you're doing
> both, the fact that C11 lacks a cancellation function makes almost no
> difference (just one simple cleanup function in condvar wait).

There is a bit more, maybe. __timedwait does cleanup push and pop and
messes around with cancelbuf. (But probably I just don't understand
enough what's going on, here.)

In any case, without attributes and possible cancelation, thrd_create
becomes significantly shorter than pthread_create.

And to my limited experience having well defined atomics that are
integrated in the language, often helps to completely avoid mutexes
and conditions.

> > > and definitely allows smaller size if the application
> > > only uses them (but of course makes libc.a and larger).
> > 
> > If we use weak aliases, this basically blows up the symbol table a
> > bit.
> > 
> > When I strip my test executable, it is impressively small.
> Yes, this is one reason I don't want __-prefixed symbols for
> everything, just functions that really _need_ namespace-safe versions.
> We should probably do some linking tests against all the C11 functions
> to make sure they're not pulling in functions outside the C11
> namespace and add __-prefixed versions of those functions only, rather
> than preemptively trying to guess what needs protection.

I tried to do that already.

> > > > For the types this should be easy to have them typedef'ed to some
> > > > opaque struct.
> > > 
> > > For the types that vary per-arch, I don't see any way around having
> > > them in the bits.
> > 
> > The only types that seem to be in bits are mutex and condition. All
> > others seem to be arch independent.
> Ah yes the others are probably not needed for C11.
> > On the long we should probably have __pthread names in the alltypes.h
> > files and typedef these in pthread.h and threads.h respectively.
> That doesn't work because both sys/types.h and pthread.h have to
> expose the pthread names.
> > > As for the constants, which ones are
> > > you talking about?
> > 
> > the mtx_ constants are the critical ones.
> > 
> > thrd_error and friends can easily be mapped to EXXX error codes from
> > errno.h. Since these names are all reserved anyway, including errno.h
> > shouldn't do much harm.
> I don't think including errno.h implicitly is permitted. E* is only
> reserved when errno.h is included. Anyway this is somewhere we wasnt
> to agree with glibc on the values; I suspect they'll just use values
> 1,2,... rather than errno codes. If so, that means we really need a
> wrapper function rather than just an alias.

Hm, not sure that I follow.

I only need EBUSY, EINVAL, ENOMEM, and ETIMEDOUT, and effectively only
that these are consistent with the rest of the C library, which for
this implementation of C threads will always be musl.

> > > I don't think it's so easy to directly use the
> > > POSIX ones for C11 since they have some different semantics (flag bits
> > > vs enumeration-style) for a few.
> > 
> > the mtx_ ones are basically flags, just as the PTHREAD_MUTEX_ ones.
> > This fits well with the actual values of these in musl.
> The PTHREAD_MUTEX_* ones are not flags; each corresponds to a single
> type and they are not combinable.

ah, ok, anyhow the only one that I am really interested in is
PTHREAD_MUTEX_RECURSIVE. So perhaps I can push that down to the

> The C11 ones are combinable, but mtx_timed is useless

yes, I think I already noted that in the file that I attached to my
initial mail

> -- there's no need to care whether it will be
> used for timed operations when it's initialized.
> BTW n1570 only has 4 possible values to pass to mtx_init, but reads
> ( p2):
> "The mtx_init function creates a mutex object with properties
> indicated by type, which must have one of the six values:"
> Any idea if six is just a mistake or if there are some values missing
> from the list?

It is just a leftover, and has/willbe been corrected.

To summarize, I'd need to get


from somewhere.


:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.