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:03:39 +1100
On 26/03/2013, at 1:31 PM, Dave Fernandes <email@hidden> wrote:
> Correct me if my understanding is incorrect:
> Your "input logic" processes some input on thread 1 until it "settles". It then signals the "6502" object that input is available and waits until the 6502 picks up (copies) this data. The 6502 picks up the input data, and starts processing it on thread 2; and also tells the input logic that it can start processing the next round of input.
>
> If this is the case, then you can handle the synchronization with a shared dispatch semaphore. The 6502 thread waits on this semaphore, and the input logic thread signals the semaphore when it has settled. Once it signals the semaphore, it exits, and a new input logic "operation" is queued (dispatch_async) by the 6502 once it has copied the state from the input logic. Once the 6502 has finished processing its input, it again waits on the semaphore.
I think that sounds about right - one problem for me is that I'm not super-familiar with the terminology. (e.g. "shared dispatch semaphore"). Is that a mutex?
What Cocoa object corresponds to that? I thought NSConditionLock but having had a stab at an implementation using it it doesn't seem quite right - I get errors logged that it is being unlocked from a different thread than the one that locked it. Hmmm, yes, I thought that was the point but perhaps not. More suitable might be NSCondition. Or.....?
--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