Hi Paul, On 8/12/06, Paul Martz <[EMAIL PROTECTED]> wrote:
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.
As long as its no more scewed up than before it'll be a good thing!
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?
Guarding against mulitple lock and unlocks being called by the same thread is what ReentrantMutex is all about. It avoids the mulitple lock so only ever needs to do one unlock. OpenThreads::Mutex is designed not to be reentrant so this type of usage is not safe, so it should be ok not worry about trying to match th EntrerCriticalSection/LeaveCriticalSection. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
