Re: multithread strange lockups in 10.3.9 and not tiger
Re: multithread strange lockups in 10.3.9 and not tiger
- Subject: Re: multithread strange lockups in 10.3.9 and not tiger
- From: Nicolas Berloquin <email@hidden>
- Date: Wed, 16 Nov 2005 16:21:59 +0100
I'd like to be a bit more precise in my description.
My two threads get dead-locked.
- Thread1 does the following :
@synchronized(mainlock) {
(...)
@synchronized(inner_object) { <--- here
}
}
- Thread 2 :
@synchronized(mainlock) { <--- here
}
sleep();
- Now, Sample show a lock at :
Thread1 : @synchronized(inner_object) {
Thread2 : @synchronized(mainlock) {
The inner_object isn't accessed from thread2. I'm pretty sure that
thread1 can't get to the second @synchronized() without
being able to lock the mainlock first. So it's really a problem with
waiting for
the inner_object to be lockable. But since it's a @synchronized()
call and not an NSLock(),
there shouldn't be ANYONE holding it locked anywhere else. (And hours
of testing on
different machines showed no deadlock on 10.4.x).
Should I consider this a cocoa bug and file it ?
here's an snip from the samples :
(A) is @synchronized(mainlock)
(B) is @synchronized(inner_object)
thread 1 :
(A) 274 -[NBTorrentDocument doPeriodicUpdates:]
274 -[NBPeerBank doPeriodicCalculations:]
274 -[NBPeer doHarakiriOnSocketError]
274 -[NBPiece removePeer:]
(B) 274 objc_sync_enter
274 pthread_mutex_lock
274 semaphore_wait_signal_trap
274 semaphore_wait_signal_trap
thread 2 :
274 -[NBTorrentDocumentController mainNetworkLoop:]
(A) 274 objc_sync_enter
274 pthread_mutex_lock
274 semaphore_wait_signal_trap
274 semaphore_wait_signal_trap
Thread 1 is the main thread (from cocoa).
The code in Thread 1, here, is being fired after a call from Thread 2
to performSelectorOnMainThread(), with waitUntilDone == NO.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden