Did you find a good description of askldjd's benchmark/test? Without that, it?s hard to say what their graph is depicting.
I explained below how the traditional Windows locks keep track of RecursionCount. It seems super-cheap/non-measurable to me. Dan -----Original Message----- From: Dave Thaler Sent: Wednesday, March 1, 2017 5:10 PM To: Thiago Macieira <thiago.macieira at intel.com>; iotivity-dev at lists.iotivity.org; Daniel Mihai <Daniel.Mihai at microsoft.com> Subject: RE: [dev] proposal to enable PTHREAD_MUTEX_RECURSIVE FYI, see https://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ for an overview, including a graph of overhead of recursive mutexes in Boost.Thread. Not sure if it applies to other implementations, but it's an interesting data point and discussion there. -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, March 1, 2017 4:58 PM To: iotivity-dev at lists.iotivity.org; Daniel Mihai <Daniel.Mihai at microsoft.com> Subject: Re: [dev] proposal to enable PTHREAD_MUTEX_RECURSIVE On segunda-feira, 27 de fevereiro de 2017 22:00:44 PST Daniel Mihai via iotivity-dev wrote: > Thanks for the feedback Jong-Min. Here are my thoughts about what you said: > > > 1. Do you have data that suggests a significant perf overhead > inflicted by PTHREAD_MUTEX_RECURSIVE? I know that on Windows the > recursion count is a simple counter ? maintained with simple > (RecursionCount++) and (RecursionCount--). It doesn?t even need Atomic > increments/decrements. I wouldn?t expect that kind of counter overhead > to be measurable or perceptible in IoTivity. The PTHREAD recursion > counter cannot be much slower than the Windows counter. I doubt that it's measurable. A quick check of the glibc source code shows that the difference is rather minimal (though it's non-zero). Unless you're doing very frequent and short lock/unlocks, I don't think we'll ever notice -- the difference should be less than 10 CPU cycles. In terms of cost: PTHREAD_MUTEX_NORMAL < PTHREAD_MUTEX_ERRORCHECK < PTHREAD_MUTEX_RECURSIVE The errorchecking mutex (returns EDEADLK) and the recursive one need to obtain the thread ID, while the normal one doesn't even try. That and the recursion counter are the difference. But obtaining the thread ID inside libc itself is very cheap and the recursion counter is not atomic anyway. > Or, did you refer to memory overhead rather than performance? Non-issue. GNU libc's NPTL mutexes don't allocate memory, ever. I have not looked into Bionic (Android's libc) implementation. Past experience with Bionic's quality has left me with no desire to look into it again. If Bionic has performance issues, it's SEP. https://en.wikipedia.org/wiki/SEP_field > Does anyone else have thoughts about my proposal? I'm just surprised that you'd think it difficult to implement for Windows. That said, I can relate the experience from D-Bus: ancient versions used non- recursive mutexes, but it needed to implement recursion on top of those for some operations. At some point it began requiring recursive ones, which then became the default, and later, the only used type. It's easy to implement a non-recursive mutex on top of a recursive one with nothing more than an extra boolean, if we ever need it somewhere, and that doesn't trip thread checking tools. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
