On Oct 8, 2014, at 3:15 PM, Jens Alfke <j...@mooseyard.com> wrote:
> On Oct 8, 2014, at 12:28 PM, Ken Thomases <k...@codeweavers.com> wrote:
>>
>> Queues are not like run loops nor threads. Your desire to have ongoing
>> logic occur on a particular queue seems odd to me.
>
> I don't think it's odd to want an ongoing single flow of control for specific
> parts of the program. Limiting parallelism makes it a lot easier to reason
> about the code's behavior.
We're not talking about parallelism here, at least not any more so than you
already had by having A and B. We're talking about (a)synchronicity, which is
a separate thing.
For example, this is still serial execution (of this local logic) and a "single
flow of control":
mainThreadTask1();
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,
0), ^{
backgroundTask1();
dispatch_async(dispatch_get_main_queue(), ^{
mainThreadTask2();
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
backgroundTask2();
dispatch_async(dispatch_get_main_queue(), ^{
mainThreadTask3();
// etc.
});
});
});
});
> You can create one of those with a background thread, but my understanding is
> that we're encouraged to use serial dispatch queues instead.
I don't know where you got that impression, but that seems like a terrible idea
to me. First of all, a queue is just a data structure. A queue doesn't run
anything, itself. It is still serviced by threads. If you're not using the
data management features of the queue — its width, suspending/resuming, barrier
tasks, etc. — there's little point.
Submitting long-running tasks to a global concurrent queue is a perfectly
acceptable way to get them to run on a background thread. Some people object,
but I have no problem with it. It doesn't have any particular advantage over
spawning a thread, though.
But using a custom queue for that, just to avoid creating a thread explicitly,
seems pointless to me. And I especially don't see the point in using a serial
queue when you don't need to synchronize.
>> The main purpose for custom queues would be to synchronize access to
>> specific resources. Why is there "logic on queue A" that's doing anything
>> other than briefly accessing a shared resource?
>
> I disagree about that, actually. The advice to wrap critical sections in
> dispatch_async calls turns out to produce a _lot_ of overhead. I briefly used
> it in some performance-sensitive code this spring, but had to rip it out
> because a large fraction of runtime was being spent in OS code that scheduled
> dispatch queues, copied/freed blocks, juggled retain counts, etc. It was a
> lot faster to just use @synchronized, and faster still to make the classes in
> question single-threaded and push the synchronization tasks up to a higher
> level of the code. (This isn't just obsessing over clock cycles; I'm
> literally talking about 2x performance improvements in high-level benchmarks.)
That doesn't seem like a disagreement to me. I said that's the purpose for
custom queues. You say they aren't well suited for the purpose. That doesn't
change the fact that that's their purpose. If you find them poorly suited,
then that's all the stronger argument not to use them.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
