Posting the submission here as well...
On Tue, Nov 19, 2013 at 3:57 PM, Mattias Helsing <helsin...@gmail.com> wrote: > 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 >> >>
win32threadsfix.tgz
Description: GNU Zip compressed data
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
