I would start by filing an RFE bug to the libdispatch tracker, since this is a complex request that may take some time to implement. Here's the link:
http://libdispatch.macosforge.org/trac/newticket
The dispatch_queue_create() function and the dispatch_queue_attr struct could be extended to specify a realtime queue [1]. The pthread_workqueue_attr struct could be extended to support a time_constraint_policy for the worker threads [2]. Each realtime dispatch_queue would use a separate pthread_workqueue whose threads would run with the desired time_constraint_policy.
For additional context, take a look at the pthread_workqueue code I pulled from the xnu and darwin sources:
http://mark.heily.com/src/libpthread_workqueue.tar
Regards,
- Mark
[1]
typedef struct dispatch_queue_attr { int thread_policy; struct thread_time_constraint_policy ttcpolicy; } dispatch_queue_attr_t;
dispatch_queue_attr_t attr = { .thread_policy = THREAD_TIME_CONSTRAINT_POLICY, .ttcpolicy = { .period = ?, .computation = ?, .constraint = ?, .preemptible = 1, }, };
my_queue = dispatch_queue_create("org.jack.realtime.audio", &attr);
[2]
typedef struct { uint32_t sig; int queueprio; int overcommit; + int thread_policy; + struct thread_time_constraint_policy *ttcpolicy; unsigned int resv2[13]; } pthread_workqueue_attr_t;
+int pthread_workqueue_attr_settimeconstraintpolicy_np( + pthread_workqueue_attr_t * attr, + struct thread_time_constraint_policy *ttcpolicy);
Thanks. Before going further, I've adapted our "fine-grained" parallel code (that is using an ad-hoc Work Stealing Scheduler and a pool or RT threads..) to use libdispatch. Performances are currently much worse. - I see that using blocks is also allocating memory, which is usually forbidden in RT code (I guess "dispatch_async_f" should be used instead of "dispatch_async" right ?) - The parallel queue is DISPATCH_QUEUE_PRIORITY_HIGH, I guess that I cannot change the GCD thread priorities on the fly right? Thanks. Stéphane Letz