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
