Thanks for the ideas, Thiago! Maybe we should make these changes someday, but adding asserts to catch unsupported behavior should be good enough for now.
CRITICAL_SECTION is what we're currently using. It allows recursive acquire. An Event would work, as you said, but CRITICAL_SECTION benefits from better tools for debugging - e.g., 1. The owner thread ID is easily available 2. We can capture the stack trace of the CRITICAL_SECTION Init & Delete 3. Application Verifier catches automatically many types if incorrect usage Dan -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Wednesday, March 1, 2017 4:37 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 07:57:18 PST Daniel Mihai via iotivity-dev wrote: > 2. Disabling oc_mutex recursivity on Windows would entail designing an > IoTivity-specific lock - because the locks provided by the OS support > recursion. Why not a CRITICAL_SECTION? If not, a simple event (CreateEvent) will solve this. Unlocking is a SetEvent and locking is WaitForSingleObjectEx. I've also got a Win8+ implementation of a mostly-userspace mutex using WaitOnAddress / WakeByAddressSingle I could contribute. It's in https://codereview.qt-project.org/#/c/157030/8/src/corelib/thread/ qmutex_win.cpp, but since I wrote it all, Intel retains the copyright and I can contribute to IoTivity under the Apache licence. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
