Hi all (again) Upping this thread as Robert want some windows developer input before he merges a submission of mine. The lack of responses suggests that no-one ever used the OpenThreads::Mutex on win32 like i did (or actually how I used it on linux and then expected the same behavior on win32), but it could also be due to me not being able to explain the problem properly so lets try again. The major problem is the OpenThreads::Mutex behaves differently with the win32 CriticalSection and linux pthreads back-ends, i.e. the Mutex is recursive on win32 but not on linux. Furthermore the api of OpenThreads wasn't fully implemented regarding the MutexType (Recursive or normal). Implementing this feature also solves the first issue. My submission implements OpenThreads::Mutex::MUTEX_RECURSIVE using CRITICAL_SECTION (this solution was previously used regardsless of user selected MutexType), but WaitForSingleObject() type semaphores for MUTEX_NORMAL type mutexes. This makes my simulators behave on both windows and linux but perhaps there are some documented or undocumented drawbacks with Create/ReleaseSemaphore and WaitForSingleObject that I am not aware of ?
regards Mattias On Sat, Dec 15, 2012 at 4:00 PM, Mattias Helsing <helsin...@gmail.com> wrote: > Hi all > I wanted to bring this up here before posting on osg-submissions. > > I have been bit for the third time now with using OpenThreads::Mutex as a > simple synchronization point between threads. My usage is typically that I > need some functionality to run in parallell to the frame loop but I need to > tell it when to start the next loop from the frame thread. So I derive from > OpenThreads::Thread and have a OpenThreads::Mutex as a member of my new > thread class, then have a lock at the start of the parallell thread's main > loop waiting for a mutex to be released. > > This works great for a week so until I test my app on windows and things > start to misbehave... Because on linux, with pthreads as the OpenThreads > backend, a lock is a lock is a lock and it doesn't matter from which thread > somebody tries to take a new lock, i.e. mutex is not recursive. While on > windows with CriticalSection (which is the Mutex backend on win32) the > thread that has the lock can relock it as many times as it likes, and from > what I read this by design and an important part of how Windows works. > > Already ranting...will try to come to point. > > All the above is ok, except that OpenThreads::Mutex works differently on > win32 and linux. Now - I have an implementation using Semaphores on windows > that makes Mutex work the same on win32 as with phtreads. My moves the > current behaviour to the OpenThreads::ReentrantMutex (which is currently not > implemented on win32). However - there is also some code in OpenThreads that > can only be enabled by manually defining USE_CRITICAL_SECTION that leads me > to believe that someone is already working on this or a similar problem. > > I'm getting more and more experienced in finding and fixing thread > synchronization problems (and want to avoid it as much as I can ;) , but > can't say I know everything about threads, so If you feel the urge to tell > me that i'm using the Mutex class in a bad way then please teach me bwana. > BUT the bottom line is still that the OpenThreads::Mutex class works > differerently on win32 and pthreads. We should fix it IMHO. > > Avaiting your input or will post to osg-submissions (yes, it's a threat :) > /Mattias > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
