[libdispatch-dev] Regarding Grand Central Dispatch

[Arild Nilsen]

Hello,

My name is Arild Nilsen, and I'm a fourth year computer science student at
the University of Tromsø. This semester I'm looking into Grand Central
Dispatch (GCD) - Apple's new approach to multicore utilization. In that
context I have a couple of questions about GCD's kernel-level support. I
would appreciate if someone could answer and/or comment on the following:

GCD is centered around blocks that are scheduled on thread pools. According
to Apple's white
paper<http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf>about
GCD, "the thread pools are dynamically sized by the system to maximize
the performance of the applications using GCD while minimizing the number of
idle or competing threads."

Exactly how is the system monitoring and dynamically adjusting the size of
these thread pools? From what I have learned so far is that the GCD
user-level runtime, *libdispatch*, makes use of and forwards blocks to
an extended
pthread interface<http://www.opensource.apple.com/source/Libc/Libc-498.1.7/pthreads/pthread_workqueue.h>,
referred to as pthread_workqueue. The implementation of this
interface<http://opensource.apple.com/source/Libc/Libc-498/pthreads/pthread.c>executes
at the bottom of the user-level, and realizes pools of kernel-level
threads. However, I do not quite understand how and where these thread pools
are monitored and dynamically adjusted. Is the kernel responsible for doing
this explicitly at kernel-level? Or, on the other hand, is it done at the
the user-level, with support from the kernel, in a way that the kernel is
only concerned with time slicing the kernel-level threads?

This forum post<http://stackoverflow.com/questions/1581776/how-does-grand-central-dispatch-really-use-the-operating-system>suggests
that the kernel is responsible for creating the work pools, and
hence is aware of which kernel-level threads belong to a particular thread
pool. Moreover,
this<http://people.freebsd.org/~sson/thrworkq/pthread_workqueue.3.txt>FreeBSD
manual page for
pthread_workqueue states that: "The pthread_workqueue_*_np() functions are
used to create and submit work items to a thread pool. The size of the
thread pool is managed by the kernel based on physical resources and the
following tunable sysctl(3)...", and then it lists a couple of policy
parameters, such as, "the number of microseconds until while a thread is
idle until it is removed from the thread pool". Could anyone confirm the
correctness of the content in the forum post and manual page?

After stumbling over the two links in the paragraph above I dug into the XNU
kernel source code, and came across
pthread_internal.h<http://www.opensource.apple.com/source/xnu/xnu-1228.0.2/bsd/sys/pthread_internal.h>and
pthread_synch.c<http://www.opensource.apple.com/source/xnu/xnu-1228.0.2/bsd/kern/pthread_synch.c>.
pthreads_internal.h resembles the policy parameters in the FreeBSD manual
page, while pthread_synch.c makes use of these parameters and implements
functions for thread pool maintenance, such as, workqueue_removethread() and
workqueue_addnewthread(). This makes me believe that the kernel is actually
aware of each and every thread pool defined via the
pthread_workqueueinterface, and that the kernel is continuously
monitoring the thread pools
and adjusting them transparently to the logic at the user-level. The
user-level logic, on the other hand, is only concerned with executing blocks
on the current kernel-level threads available in the particular thread pool.
To what degree is my understanding representative to what is actually
happening?



Arild Nilsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100319/14aef52e/attachment.html>