Re: Shape of a knotty(?) threading problem
Re: Shape of a knotty(?) threading problem
- Subject: Re: Shape of a knotty(?) threading problem
- From: Dave Fernandes <email@hidden>
- Date: Tue, 26 Mar 2013 01:17:24 -0400
On 2013-03-25, at 11:03 PM, Graham Cox <email@hidden> wrote:
>
> 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?
Sorry - sloppy terminology. I meant a GCD semaphore that is shared by both threads to synchronize them. GCD semaphores are counting semaphores rather than mutexes. In this case, it is only counting between 0 and 1. The consumer thread (6502) waits on the semaphore as long as the semaphore's "count" is 0. When the count is incremented by the producer thread (input logic), the 6502 thread unblocks and knows that it has data available.
This is all C API (GCD). There is no Cocoa involved.
// Create the semaphore.
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
// Give a reference to both tasks that need it…
// Wait on the semaphore in the 6502 thread.
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// You can wait less than forever here if you want to check periodically whether you should cancel.
// Increment the semaphore's count in the producer thread.
dispatch_semaphore_signal(semaphore);
// The producer thread should exit or stop producing further "output" until the 6502 has copied the produced data.
.
.
.
// Delete the semaphore when you are done.
dispatch_release(semaphore);
>
> 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