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] |
On Fri, 2013-06-21 at 11:37 -0400, Rich Felker wrote: > On Fri, Jun 21, 2013 at 05:00:29PM +0200, Torvald Riegel wrote: > > Or should we just not try to support explicit initialization of DEFAULT > > mutexes *via settype()* and just make them NORMAL mutexes by default? > > This way, we wouldn't need to introduce a new public > > PTHREAD_MUTEX_DEFAULT value, and could still disambiguate DEFAULT from > > NORMAL when the initialization happens via static initializers or > > default mutex attributes (ie, NULL parameter). > > I'm fine with this. I don't think there's any sane reason to call > pthread_mutexattr_settype when making default-type mutexes, and I > doubt any real-world apps do it. If they do, it's their fault for > being slow; they're performing unnecessary, bloated operations in any > case and should be fixed. Ok. Attached is what I am currently testing. This doesn't touch any of the public mutex types, but disambiguates NORMAL from DEFAULT (modulo the above). All the mutex functions can then handle PTHREAD_MUTEX_NORMAL_INT_NP and PTHREAD_MUTEX_DEFAULT_INT_NP differently. This should be sufficient as a base to enable elision for the "90%", and we don't require further bits in the type. IOW, it's stage 1) in my three-stage proposal for how to commit those things we can actually agree on now. I hope to get back to this later today.
Attachment:
patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |