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 > (188.8.131.52 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.