Re: worker thread iterating over array - SLOW
Re: worker thread iterating over array - SLOW
- Subject: Re: worker thread iterating over array - SLOW
- From: Ken Thomases <email@hidden>
- Date: Mon, 31 Jan 2011 22:45:39 -0600
On Jan 31, 2011, at 8:48 PM, Peter Lübke wrote:
> Thanks Ken,
You're welcome.
> Am 01.02.2011 um 02:07 schrieb Ken Thomases:
>
>> So, you have effectively failed to shift the work from the main thread to the worker thread. The main thread is a "server" doing all of the work on the behalf of its client, the worker thread.
>
> Not quite... In this case, the worker thread is the server.
If the main thread owns the real array and the worker thread receives a proxy of the array (and thus its elements), then the main thread is the server, serving the services of the array and its elements to the worker thread. It doesn't matter how you intended/designed things to work.
> I guess that's why the main thread is all the way responsive.
This probably has to do with the granularity of the messages that the worker thread is sending to the array and its elements. If it's invoking many quick methods, then the main thread will remain responsive, even if it's doing all the work. That's because there are frequent opportunities for it to respond to GUI events between messages from the worker thread.
>> Also, you want to design a fairly coarse-grained protocol of requests that a client can make of the server -- few requests to do some big chunks of work, not many requests for small chunks of work.
>
> This is what I thought I was doing, the "bad" thing - if I get it right - is that I pass the array to the server?
Basically, yes. It's not a hard and fast rule that doing so is always wrong or bad. Just remember that every method invoked on the proxy is delivered to the original object over the D.O. connection, the provider of that original object does the work, and then results are passed back -- and if the results are non-value objects, they are passed by reference, meaning as proxies. So, the proxiness can cascade.
> There's a bunch of these arrays around, all containing objects of one class. There's another bunch of objects of various classes that access these objects.
> I didn't like the idea of implementing the creation of threads that always kind of do the same sort of work in each of these different classes.
> So I thought it might be a good idea to have a singleton "thread manager" create worker threads as needed and coordinate those different object's requests.
That's a thread pool. You can use any number of synchronization techniques to give work to the threads in a pool. NSConditionLock is nice and straightforward. See <http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html>.
There are also message queue implementations to do something a bit like D.O., except without the proxying. I've used YAMessageQueue in the past. It's also not too hard to roll your own.
Cheers,
Ken
_______________________________________________
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