Subject: Re: Update on freeze status of glibc 2.18?
Date: Wednesday 19th June 2013 22:42:34 UTC (over 4 years ago)
> 1) Don't use elision for PTHREAD_MUTEX_NORMAL because we can't fulfill > the relock requirements. I suppose giving PTHREAD_MUTEX_DEFAULT a new > value would be okay because that can happen unconditionally, and it > doesn't break existing applications (we of course would need to handle > the new value everywhere). If you change the value of PTHREAD_MUTEX_DEFAULT to a new value that old libraries don't support, then you need to use a new symbol version for pthread_mutexattr_settype. Otherwise newly-built programs would become incompatible with older shared libraries but not say so in their version requirements. (You probably don't really need a separate compatibility entry point, just an alias with the old, non-default symbol version.) > 2) Don't support elision with (nested) trylock because it can't be done > without changing the ABI; it would violate POSIX semantics. We can't ever do anything that breaks the semantics like this at all. It's possibly acceptable only if it is enabled by a new, non-default, non-standard type. But that would be a new ABI and a new symbol version for at least pthread_mutexattr_settype. > 3a) Don't allow the new MUTEX type modifiers (...ELISION_NP > and ...NO_ELISION_NP) at all because they aren't available by default > (Carlos' requirement to not have elision enabled by default) and we > don't want to introduce new API/ABI features? Or ... > > 3b) Don't allow the new MUTEX type modifiers (...ELISION_NP > and ...NO_ELISION_NP) to change semantics but be available as a > performance hint? They wouldn't break existing code, but would add new > API and ABI bits. Or ... > > 3c) Do allow the new MUTEX type modifiers (...ELISION_NP > and ...NO_ELISION_NP) to change semantics because they're new bits and > don't break existing code? My strongest requirement is that we not have a configure switch that changes what ABI is supported by the shared libraries built. That's just begging for fragmentation and confusion. So if there are any ABI additions, they would have to be unconditional ones, with the configure switch affecting only the implementation details and performance characteristics, not the semantic guarantees of the ABI. Note I say "semantic guarantees", not "semantics". For example, there might be a new type whose semantics are "trylock might lie" (or whatever it is), in which case it's OK if the actual behavior of trylock differs observably between the --disable-foo and --enable-foo builds as long as both are within the range of behaviors the new ABI says it might have. That said, I am pretty skeptical about adding any API/ABI features at all when their only meaning is for non-default code that is not really ready for prime time. Whatever ABI features we introduce, we'll be stuck with forever, even if they turn out to be useless or not the ideal fit for the implementation we eventually wind up with. In contrast, changing PTHREAD_MUTEX_DEFAULT to a new, unique value would be just fine. Rather than meaning any particular thing fixed at compile time, it would just mean "do what you think is best for me". That's an ABI that will make sense in the future whether it results in the current or future PTHREAD_MUTEX_NORMAL or results in something else (that at least meets the POSIX mandate for PTHREAD_MUTEX_NORMAL). > 4) Don't allow the performance tuning env vars at all because they add > new API? Or is this okay because of our guidelines that explicitly > exclude the tuning env vars from ABI guarantees? I object to environment variables for completely separate reasons. > Which of these are true and which aren't? Any other notable > consequences that are missing in the list above? Aside from symbol versioning requirements for any kind of ABI addition, nothing pops to mind. > If 1, 2, 3a and 4 are correct (and we can give PTHREAD_MUTEX_DEFAULT a > new value), then this would mean that a configure switch would enable > elision for most mutexes (assuming most are of DEFAULT type) in freshly > compiled programs. I do think this is doable. Thanks, Roland