Re: multithread strange lockups in 10.3.9 and not tiger (followup)
Re: multithread strange lockups in 10.3.9 and not tiger (followup)
- Subject: Re: multithread strange lockups in 10.3.9 and not tiger (followup)
- From: Nicolas Berloquin <email@hidden>
- Date: Wed, 16 Nov 2005 17:01:31 +0100
Woops there's a slight correction to what I said.
inner_object *can* be used as a lock on both threads.
However, at the place of the call to @synchronized(mainlock) in
thread 2,
no locking has been done on inner_object.
Actually, from what I deduce from the samples, thread 2 got locked
after thread 1,
and is blocking on mainlock, which is normal behavior.
What is not normal, is the blocking in the inner_object, which, as I
said
can't be (practically) locked at that time by any other thread.
On 16 nov. 05, at 16:21, Nicolas Berloquin wrote:
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
_______________________________________________
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