[libdispatch-dev] Clarification on default target_queue for custom serial queues
jocke at tbricks.com
Sun Jun 26 03:14:44 PDT 2011
Also for the record, this is the exact behaviour of the portable libpthread_workqueue implementation uses on other platforms as well.
This email was sent from my iPhone, so it may be unusually terse.
On 26 jun 2011, at 02:14, "Daniel A. Steffen" <dsteffen at apple.com> wrote:
> On Jun 25, 2011, at 5:08 PM, DrPizza wrote:
>> 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.
> libdispatch-dev mailing list
> libdispatch-dev at lists.macosforge.org
More information about the libdispatch-dev