Thanks for the futher explanation, very subtle, but yes this looks like a potential bug so very well spotted.
I believe it is a very unlikely problem to arise in action due the the fact that in lock() _threadHoldingMutex is set first, then _lockCount is set to 1, which will probably avoid most cases even when the two threads are very close.
While a very low risk there is the potential for the problem, and for a fix should it should be sufficient to reset the _threadHoldingMutex to 0 just before the Mutex::unlock() in ReentrantMutex::unlock().
I have applied fixed this and checked it into CVS. Let me know if this one gets through your very through review :-)
Robert.
On 9/15/06, Schmidt, Richard, SDGE1
<[EMAIL PROTECTED]> wrote:
Mhh, ok difficult to explain (for me):
The important part is
"_threadHoldingMutex==OpenThreads::Thread::CurrentThread() &&
_lockCount>0" in ReentrantMutex::lock().
You have to take into account that one noted above is not an atomic
operation, so between
"_threadHoldingMutex==OpenThreads::Thread::CurrentThread()"
and
"_lockCount>0"
the other thread may get some time, trying to lock the ReentrantMutex.
Richard
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
