Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: "Matt Budd (Madentec)" <email@hidden>
- Date: Mon, 14 Nov 2005 09:03:56 -0700
Right, but the whole problem with what I was doing, is that what you
are describing is the scenario I want to happen...but it is not
_guaranteed_ to happen. This is the scenario you are describing and
what I would ideally like to happen:
1. WT acquires lock
2. <swap>
3. MT attempts to lock -- blocks because WT has lock
4. <swap>
5. WT finishes its iteration and unlocks
6. WT sleeps for 0.05 seconds
7. <swap>
8. MT unblocks because WT no longer has lock
9. MT modifies array
10. <swap>
11. WT attempts to lock to start next iteration -- blocks because MT
has lock
12. <swap>
13. MT finishes modifying array and unlocks
14. <swap>
15. WT unblocks because MT no longer has lock
16. WT locks the lock and is now working with the correct "state"
The problem is, step 7 might not happen right then In that case, we
get the following:
1. WT acquires lock
2. <swap>
3. MT attempts to lock -- blocks because WT has lock
4. <swap>
5. WT finishes its iteration and unlocks
6. WT sleeps for 0.05 seconds
7. WT loops around for its next iteration and locks the
lock...incorrect because WT is still in old "state" even though MT
has an update waiting
The issue is that there is no guarantee who will get the lock first,
and it is possible for the WT to be working based on a state that is
not current. You're statement below is the heart of the problem:
"[the main thread] will acquire the lock (which means it will block
until the worker thread is done with its present iteration)". I don't
think that this is absolutely true...it will block until the worker
thread unlocks and it is swapped back in time to lock it...the worker
thread might get to do another iteration if the MT is not swapped in
in time.
That's why I think I either have to do the command structure where
only one thread is modifying the array, or else implement a FIFOLock
where I even if the WT gets a chance to do an iteration before the MT
gets swapped in to lock it, it knows that someone is waiting to lock
it so it just gets in line and waits. I've already partially
implement a FIFOLock, so I think I am going to go that route. I have
to add a couple of things to what I posted on Thursday, but I think
I've figured it out.
Thanks for the input though. I realize that most of the time, this
won't be an issue, and perhaps I am trying to over-design things. I'm
sure that Apple has put stuff in on their end too make sure that
things are fairly fair and that things get swapped and such
adequately, but I can still see a case where it potentially fails.
- Matt
On Nov 10, 2005, at 5:38 PM, Joseph Kelly wrote:
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.
Correct me if I am wrong, but isn't that exactly what your code
does? The worker thread is always doing its thing, and then
whenever the main thread wants to modify an element in the array
("update the state"), it will acquire the lock (which means it will
block until the worker thread is done with its present iteration),
the worker thread will unlock, and the main thread will unblock and
change the state of array. At the same time, the worker thread will
loop back to the top, and attempt to lock, but if the main thread
still has the lock, the worker will block. When the main thread is
done changing the state and unlocks, the worker thread unblocks and
goes on its merry way.
joe
_______________________________________________
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