> Don't know, I haven't been party to the Windows OpenThreds > implementation, but my guess is that the contributors were > learning threading/MS's thread API while developing the code. > Alot of code is developed this way, OpenSceneGraph wouldn't > exist if it weren't for the spirit of having a go at > something you've never done before ;-)
Well, in THAT spirit, then let me give it a whack... :-) I've rewritten Mutex using a CRITICAL_SECTION which eliminates the need for spinning so it should address the performance issues. While I'm rebuilding OSG for testing I thought I'd post some questions and see how bad I screwed things up. With a Win32 CRITICAL_SECTION, we call EnterCriticalSection to hold a lock and LeaveCriticalSection to release the lock. The problem is, these are paired calls; if a thread calls EnterCriticalSection twice, it must then call LeaveCriticalSection twice to release the lock. If I'm not mistaken, this is what osgDB::ReentrantMutex does, which implies that OpenThreads::Mutex should not work this way. Correct? If so, then I'll need to add some additional code to prevent this from happening. I'm also unsure of what the semantics and return code should be for trylock(): * Should this function take the lock if it can? What should the return code be in this case? * If the current thread can't take the lock, what should the return code be? * Finally, if the current thread already owns the lock, what should the return code be? Thanks, -Paul _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
