On 26/03/2013, at 2:20 PM, Ken Thomases <[email protected]> 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 protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
