Re: Shape of a knotty(?) threading problem
Re: Shape of a knotty(?) threading problem
- Subject: Re: Shape of a knotty(?) threading problem
- From: Graham Cox <email@hidden>
- Date: Tue, 26 Mar 2013 14:35:29 +1100
On 26/03/2013, at 2:20 PM, Ken Thomases <email@hidden> wrote:
> Your first task is to figure out how you want to deal with that parenthetical. That sounds like it's wholly within your problem domain and so not something that we can help much with.
Yes, that's fair enough - I wasn't really asking about that, but writing it down helped to formulate the problem space more clearly in my mind. For now I'll just count simulation cycles and see if I can come up with something better later.
> In general, it's not safe to kill threads from outside. Instead, whatever blocking mechanism you choose should have a means of being woken from outside. You then set some state that indicates to the thread that it should exit itself and make sure the thread checks that and does so. Then you set that state and wake the thread.
OK, I have this.
>> So my question is, does this sound like a feasible way to approach this?
>
> Yes.
That's a really great piece of news since it means it's down to details, not architecture :)
>> If so, what sort of thing is this lock - would NSConditionLock be useful here? Does it do what I'm supposing it does - block one thread until another thread satisfies the condition?
>
> It can work that way. The lock has a state value. The meaning of that value is defined solely by your code. Cocoa doesn't interpret it. A caller can lock the lock unconditionally or it can attempt to lock it only when the state value has some specific value. Whenever a thread which has previously locked the lock unlocks it, it may set a new state value.
>
> Putting those things together, you can achieve "block one thread until another thread satisfies the condition".
>
>> If so, a brief example of its use would be gratefully received. Or some other completely different solution....
>
> I'd define some state values like:
>
> enum {
> DATA_LINE_IDLE,
> DATA_LINE_READ_IN_PROGRESS,
> };
>
> Initialize the lock with [[NSConditionLock alloc] initWithCondition:DATA_LINE_IDLE];
>
> Then, when the CPU simulator does a read, it does [lock lockWhenCondition:DATA_LINE_IDLE], it issues the read to the simulation thread (asynchronously), and then does [lock unlockWithCondition:DATA_LINE_READ_IN_PROGRESS]. It then immediately tries to lock it again with [lock lockWhenCondition:DATA_LINE_IDLE], gets the result of the read from some storage somewhere, and unlocks the lock without changing its value with [lock unlock].
>
> When the simulation thread has completed the read (however you determine that), it should lock the lock unconditionally with [lock lock], store the results where the CPU simulator expects to find them, and unlock it with [lock unlockWithCondition:DATA_LINE_IDLE].
>
> When a controller thread needs to shut things down, it will have to lock the lock unconditionally with [lock lock]. Then, it sets a flag that the CPU simulator will understand means it needs to exit, and it unlocks the lock with [lock unlockWithCondition:DATA_LINE_IDLE]. That's the condition that the CPU simulator thread is blocked on, so it will wake and check the termination flag, and terminate.
OK, this seems more complicated than my simple-minded attempt so I'll try with this approach and see how it goes.
The lock object - at the moment I have that as an ivar of the object that handles this, and I reuse it for every memory access. That is reasonable, right? I mean, because every single memory access has to bottleneck through the same address and data lines, they are the shared resource that I'm effectively locking access to.
Thanks very much for the help.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden