I agree that killing the recursion count for Windows is not terribly difficult. However, I would prefer an oc_mutex that maps directly to an object provided by the OS - instead of oc_mutex adding its own value.
But, I gave up on my proposal based on the persistent feedback that non-recursive locks lead to higher quality code. That is different from my experience - code seems to be just as bad when using either recursive or non-recursive locks. But, if other folks feel that way, it's hard to debate their experiences. Dan -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Wednesday, March 1, 2017 4:58 PM To: iotivity-dev at lists.iotivity.org; Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: jminl.choi at samsung.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
