[libdispatch-dev] Clarification on default target_queue for custom serial queues

Daniel A. Steffen dsteffen at apple.com
Sat Jun 25 17:14:01 PDT 2011

On Jun 25, 2011, at 5:08 PM, DrPizza wrote:

>> it is this 'true' here that makes all the difference, the default target
>> queue of a serial queue is the _overcommit_ default-priority global
>> concurrent queue.
>> For items/queues submitted to an overcommit global queue, the current Mac OS
>> X kernel workqueue mechanism creates threads more eagerly, e.g. even if an n-
>> wide machine is already fully committed with n cpu-busy threads, submitting
>> another item directly to the overcommit global queue or indirectly to a
>> serial queue with default target queue will cause another thread to be
>> created to handle that item (potentially overcommitting the machine, hence
>> the name).
>> If you wish to avoid this, simply set the target queue of your serial queues
>> to the default priority global queue (i.e. non-overcommit).
>> The overcommit/non-overcommit distinction is intentionally undocumented and
>> only available in the queue_private.h header because we hope to revise the
>> kernel workqueue mechanism in the future to avoid the need for this
>> distinction.
> Do the present non-overcommit queues still do the Right Thing if all threads are currently non-busy-but-blocked? In other words, will they let me deadlock by submitting N units of work that require the N+1th to succeed (with N+1 being kept on the queue because the system won't spin up any more threads)? I know there is specific language about this situation in the code (for codepaths that use raw pthreads rather than workqueues), but I'm not sure how the workqueue situation is handled.

yes, blocked threads are handled differently than cpu-busy ones, even on the non-overcommit workqueues new threads will be created if there are blocked threads (and fewer than than n cpu-busy threads for a n-wide machine).

The kernel imposes an overall limit to the total number of workqueue threads per process, so if N is too large you can still deadlock yourself by blocking too many threads.


More information about the libdispatch-dev mailing list