Re: [osg-users] OpenThreads::Mutex doesn't work the same on win32 and linux/pthreads
Hi OSG users especially Windows experts, Please could you have a look at what Mattias is proposing and provide feedback. I don't have Windows machine let alone expertise with Windows threads so can't directly contribute insights to the specifics of the Windows threads implementation so have to defer to the community to provide the expertise. The only thing I'd add in general is that having OpenThreads behave the same across all platforms is desirable so in principle I believe Mattias's suggestion is sound. I'm a litle cautious though as there is chance that Windows only OSG applications might be relying upon the re-entrant nature of the current Mutex under Windows so could find there application hanging with the integration of the change to OpenThreads. Thoughts please ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads::Mutex doesn't work the same on win32 and linux/pthreads
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
Re: [osg-users] OpenThreads::Mutex doesn't work the same on win32 and linux/pthreads
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
[osg-users] OpenThreads::Mutex doesn't work the same on win32 and linux/pthreads
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
