Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: Joseph Kelly <email@hidden>
- Date: Thu, 10 Nov 2005 14:52:02 -0800
I'm not certain I understand the difficulties you are encountering.
It looks like, from this program snippet, that _aoNumbers is well
protected by the _oAllowedToAccumulate lock. Now if you want to
control the worker thread, you've got to implement some kind of
messaging system. The most basic thing to do is have your main thread
acquire the lock from the start, and when its ready for the worker
thread, do an unlock.
If you want to minimize blocking time, then make _aoNumbers belong to
the worker thread, and then add a synced command queue. The main
thread acquires the lock on the queue, adds a command, and unlocks.
Meanwhile, the worker thread can check the queue (i.e. lock, checks
it for new commands, unlocks it).
joe
On Nov 10, 2005, at 1:18 PM, Matt Budd (Madentec) wrote:
Thanks Joseph and Shawn for the replies. I guess it comes down to
the fact that there is no inherent order, but it probably does a
decent job of assigning locks fairly.
Perhaps expanding on my exact situation might help. I have since
realized I don't need 3 threads, but instead have 2 threads (the
main thread and a worker thread). The worker thread loops through
an array of numbers and adds a certain amount to those number
depending on the direction. The main thread either changes the
direction for each of those numbers or adds more numbers (with an
initial direction) to the array. But basically, I don't want the
worker thread to add to the numbers if I am changing the direction
or adding numbers. Here's some more detailed psuedo-code (typed in
Mail so don't mind any typos):
- (void)handleWorkerThread: (id)poPassedObject
{
NSAutoreleasePool *loThreadPool = [[NSAutoreleasePool alloc]
init];
while (YES) {
NSAutoreleasePool *loLoopPool = [[NSAutoreleasePool alloc]
init];
[_oAllowedToAccumulate lock];
NSEnumerator *loNumberIterator = [_aoNumbers
objectEnumerator];
NSMutableDictionary *lyNumber;
while ((lyNumber = [loNumberIterator nextObject]) != nil) {
[lyNumber setValue:
[NSNumber numberWithInt: (
[[lyNumber
valueForKey: @"number"] intValue]
+ [[lyNumber
valueForKey: @"direction"] intValue]
)
]
forKey: @"number"
];
}
[_oAllowedToAccumulate unlock];
[NSThread sleepUntilDate: [NSDate
dateWithTimeIntervalFromNow: 0.05]];
[loLoopPool release];
}
[loThreadPool release];
}
- (void)setDirection: (int)piDirection forNumber: (int)piIndex
{
//This is called on the main thread
[_oAllowedToAccumulate lock];
NSMutableDictionary *lyNumber = [_aoNumbers objectAtIndex:
piIndex];
[lyNumber setValue: [NSNumber numberWithInt: piDirection]
forKey: @"direction"];
[_oAllowedToAccumulate unlock];
}
- (void)addNumber: (int)piNumber
{
//This is called on the main thread
[_oAllowedToAccumulate lock];
[_aoNumbers addObject: [NSMutableDictionary
dictionaryWithObjectsAndKeys:
[NSNumber
numberWithInt: piNumber],
@"number",
[NSNumber
numberWithInt: +1],
@"direction",
nil
]
];
[_oAllowedToAccumulate unlock];
}
The problem is that if I call -setDirection:forNumber: or -
addNumber: from the mail thread, it might block if the worker
thread is busy accumulating. And at that point, I know that there
is a state change (either a direction or cardinality change), so I
want the accumulator to block the next time it goes to acquire the
lock. But this code doesn't guarantee this...it is possible here
for the main thread to block in either of the latter two methods,
and then the worker thread gets swapped in and re-locks the lock
before the main thread can.
Any suggestions? I can't use conditional locks, because I end up
with the same scenario...in the main thread I'd have to lock it
first to unlock it with a condition and then in the worker thread
I'd have to lock when the condition was "no state change pending".
But then if I did get that lock in the worker thread, the main
thread would block before it could lock it to unlock it with the
condition "state change is pending", so it would be possible for
the same scenario...
- Matt
_______________________________________________
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