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
