Hi Dan, On Mon, Feb 27, 2017 at 10:00 PM, Daniel Mihai via iotivity-dev < iotivity-dev at lists.iotivity.org> 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. > > Or, did you refer to memory overhead rather than performance? > > Do you have examples for scenarios where debugging becomes harder with > recursive locks? > > 2. I agree that sometimes we need to test on multiple platforms. > But, when we can save some of that time and energy, especially **without > paying a significant cost**, I strongly believe that driving towards > consistent behavior for multiple platforms is a worthy goal. I am not aware > of a significant cost for the change we are discussing here. > > 3. I agree this is possible. #1 and #2 are more important than #3. > > > > Does anyone else have thoughts about my proposal? > Dave Butenhof's old discussion about recursive mutexes makes some excellent points about why recursive mutexes shouldn't be used: http://zaval.org/resources/library/butenhof1.html I think it would be better to consistently use IoTivity locks in a non-recursive manner, even on platforms that only support recursive locks, rather than force all IoTivity locks to be recursive. -Ossama -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170301/30ac6fbb/attachment.html>
