Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: "Matt Budd (Madentec)" <email@hidden>
- Date: Thu, 10 Nov 2005 16:30:54 -0700
Hey Joseph,
I can't do the first suggestion, because that implies that the worker
thread is being turned on sporadically to do some work. It is the
opposite case, the worker thread is constantly evaluating these
numbers and accumulations, and only sporadically the main thread is
going to interrupt him and tell him to either accumulate in a
different direction or to start also accumulating additional numbers.
The the worker thread is going all the time, I just want to stop it
when I know there is an state update going to happen.
Your second idea makes a lot of sense. I would have to basically keep
a command queue that says 1) change direction at index 1; 2) add new
number with initial values; 3) change direction at index 5; etc.
This would work, because then the array would only be modified in the
worker thread. The only problem I see is that the main thread would
have to search the array for the correct number to update and then so
would the worker thread. This is potential for a bit of duplicate
processing, but it might not be that bad of overhead. I will try this
over the weekend and see how it goes...if not, then I might just
stick with my FIFOLock I posted earlier (unless someone finds
something wrong with it).
Thanks for the suggestions!
- Matt
On Nov 10, 2005, at 3:52 PM, Joseph Kelly wrote:
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