Re: User-space threads and NSAutoreleasePool
Re: User-space threads and NSAutoreleasePool
- Subject: Re: User-space threads and NSAutoreleasePool
- From: Michael Ash <email@hidden>
- Date: Thu, 18 Mar 2010 22:56:15 -0500
On Thu, Mar 18, 2010 at 12:05 PM, Jens Alfke <email@hidden> wrote:
>
> On Mar 18, 2010, at 8:35 AM, Michael Ash wrote:
>
>> Cocoa keeps around a lot of thread-specific state. In addition to
>> autorelease pools, you also have exception handlers, graphics
>> contexts, and possibly others.
>
> Yup. I quickly ran into this in 2008 when experimenting with implementing
> coroutines (which use the same ucontext stuff.) Lightweight
> threads/coroutines can be very useful for highly scalable systems — that's
> one reason there's a lot of hype about Erlang these days — but you can't
> graft them on top of a runtime that doesn't know about them and already has
> its own threading support.
>
> I haven't had a chance yet to use the Grand Central / dispatch-queue stuff
> in 10.6, but I believe that it offers some similar functionality, like being
> able to create huge numbers of concurrent operations without having each one
> create a kernel thread.
GCD sort of kind of offers this. The big difference with GCD is that
the individual jobs submitted to GCD can't be preempted, except by the
normal rules of preemptive multithreading (GCD worker threads are just
pthreads). If you load up GCD with enough jobs to keep your CPU busy,
then submit one more job, that job has to wait until a running job
completes before it gets a chance to run. You can get more granularity
by dividing your work into smaller jobs, of course.
Where GCD can really shine for tasks like the original poster
mentioned is with dispatch sources. These allow you to, among other
things, manage asynchronous I/O using callbacks in a way that's pretty
easy to write and gives you good performance. You can basically just
load up GCD with file descriptors to monitor, and it'll call you when
data is available (or when space is available for writing). By using
blocks, your code looks close to what it would look like with
synchronous I/O, you don't have to use one kernel thread for each I/O
source, and if you do intensive computations on multiple I/O sources,
GCD will give you a multicore speedup pretty much for free.
Mike
_______________________________________________
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