Re: An extremely weird slowness...
Re: An extremely weird slowness...
- Subject: Re: An extremely weird slowness...
- From: Greg <email@hidden>
- Date: Mon, 21 Nov 2005 05:01:48 -0800
- Thread-topic: An extremely weird slowness...
Inside this loop:
for (NSEnumerator *en=[scheduledToSetCurrentLock
objectEnumerator];dbo=val2id([en nextObject]);) {
DBXLock *lock=[DBXLock currentLockFor:dbo];
[dbo setCurrentLock:lock];
NSLog(@"has returned");
}
The current thread attempts to acquire a shared resource:
[dbo setCurrentLock:lock];
If this resource is already in use, then this thread will block until the
thread holding the lock on that resource, dbo, unlocks it.
So why is that other thread taking so long to unlock dbo? Perhaps that
thread is waiting for the current thread to unlock a different object that
it had locked at some earlier point in time. In other words, each thread
remains blocked until the other thread is no longer blocked. This situation
is known as "deadlock".
A similar problem is "livelock" when two threads keep repeating actions that
would succeed on their own, but when taken at the same time, fail. An
analogous situation occurs when two cars arrive at a four way stop at the
same time. Each car waits for the other car to proceed, then decides to go
at the same time, cannot, decide to wait for the other car to go first
again, gets tired of waiting at the same time, and so on and so forth, with
neither ever making it through the intersection.
Synchronization problems can be very difficult to debug, so they are best
avoided when possible. Generally, use locks minimally, and only when
necessary. For programs with threads that could hold more than one locked
resource at the same time, each thread must then lock and unlock the
resources in the same order as every other thread. Doing so is necessary to
prevent deadlock, livelock and other race conditions.
Unfortunately locking an object retrieved by enumerating an array, as this
code does, could not be providing such an in-order guarantee, if one is in
fact needed. Since there definitely appears to be some kind of resource
contention problem, I would recommend cataloging how - and in what order -
objects are being locked and unlocked.
Greg
On 11/21/05 3:21 AM, "Ondra Cada" <email@hidden> wrote:
> Hello all,
>
> I've got a slow code, and I fear I have no idea what the heck might
> be causing the problem. I've found the loop which takes an eternity;
> it looks like this:
>
> for (NSEnumerator *en=[scheduledToSetCurrentLock
> objectEnumerator];dbo=val2id([en nextObject]);) {
> DBXLock *lock=[DBXLock currentLockFor:dbo];
> [dbo setCurrentLock:lock];
> NSLog(@"has returned");
> }
>
> The one method which is interesting is the setCurrentLock: one; it
> looks like this:
>
> -(void)setCurrentLock:(DBXLock*)lock {
> currentLock=lock; // no need to retain here
> NSLog(@"about to return");
> }
>
> Now, the log shows pretty well where all the time goes to:
>
> ...
> 2005-11-21 11:13:02.585 AdnexusII[1095] about to return
> 2005-11-21 11:13:03.376 AdnexusII[1095] has returned
> 2005-11-21 11:13:03.387 AdnexusII[1095] about to return
> 2005-11-21 11:13:03.878 AdnexusII[1095] has returned
> 2005-11-21 11:13:03.897 AdnexusII[1095] about to return
> 2005-11-21 11:13:04.300 AdnexusII[1095] has returned
> 2005-11-21 11:13:04.316 AdnexusII[1095] about to return
> 2005-11-21 11:13:04.876 AdnexusII[1095] has returned
> 2005-11-21 11:13:04.886 AdnexusII[1095] about to return
> 2005-11-21 11:13:05.420 AdnexusII[1095] has returned
> 2005-11-21 11:13:05.432 AdnexusII[1095] about to return
> 2005-11-21 11:13:06.127 AdnexusII[1095] has returned
> ...
>
> WTH?!? How comes that a plain ole return takes nearly a second? Had
> it been a message dispatch, well, I dunno, selector caches might go
> wild or whatever, but this I plain don't get :-O Far as I can say,
> the rest of the application works normally -- I haven't encountered
> anything like that elsewhere.
>
_______________________________________________
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