[opensource-dev] Snowglobe 1.3 Deadlock..again

Robin Cornelius robin.cornelius at gmail.com
Fri Feb 12 11:59:17 PST 2010

Oh no its still happening, thanks to Opensource Obscure for the back
traces. This time its a different interaction to SNOW-196. It seems
this is a less common deadlock for most people but there are a few
still getting it and Opensource seems to get it very repeatably.

What appears to be happening is that two worker threads are running on
the same image, one is doing a
LLImageDecodeThread::Responder::Complete() and the other is trying to
start a new decode via  LLTextureFetch::doWork(). So i guess this
situation can occur after you have decoded one discard level and new
data has appeared and another discard level has been achieved so a new
decode has been started. When then combined with a specific test on
the main thread we get a 3 way deadlock :-

Thread 1 LLTextureFetch::getRequestFinished() - Locking mQueueMutex
Spinning on mWorkMutex

Thread 3 LLImageDecodeThread::Responder::Complete() Locking
LLThread->mRunCondition Spinningon mQueueMutex

Thread 5 LLTextureFetch::doWork() Locking mWorkMutex Locking
mCreationMutex Spinning On LLThread->mRunCondition

Threads 3 and 5 are both ending up with a LLThread that is instanced
as a LLImageDecodeThread (with the same this pointer for #3 and #5) so
the LLThread->mRunCondition lock is locking those two.

I would have not though that threads 3 and 5 should be running at the
same time on the same LLThread * ? why isn't the mRunCondition mutext
locking that?

Any comments?

More information about the opensource-dev mailing list