[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406330769.6438.85.camel@eris.loria.fr>
Date: Sat, 26 Jul 2014 01:26:09 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
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.
probably.
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
here
http://gustedt.wordpress.com/2012/10/14/c11-defects-c-threads-are-not-realizable-with-posix-threads/
> 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 libc.so 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 alltypes.h.in 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
implementation.
> 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
> (7.26.4.2 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
EBUSY, EINVAL, ENOMEM, ETIMEDOUT and TSS_DTOR_ITERATIONS
from somewhere.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
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.
