On Jan 28, 2010, at 7:07 AM, Mario Schwalbe wrote:
1. Let's assume someone manages to submit n jobs that block each other causing a deadlock on a machine having n processors. The thread pool implementation isn't able to execute any other jobs anymore, so the application can be considered erroneous/dead. The work queue implementation is still able to execute jobs waiting in the queue, so the application (as a whole) can still make some progress, but cannot finish either, because - assuming the results of those blocked jobs are important - it at some point has to wait for their results (dispatch_group_wait()) which will block forever as well.
2. A deadlock requires a cycle in the dependency graph. But jobs submitted that are still waiting in the queue, won't be executed yet, and, hence, won't be able to acquire any resource to prevent other jobs from executing.
not necessarily a cycle, a dependency chain longer than the size of the thread pool is sufficient: sem1 = dispatch_semaphore_create(0); sem2 = dispatch_semaphore_create(0); dispatch_async(q, ^{dispatch_semaphore_wait(sem1);}); dispatch_async(q, ^{dispatch_semaphore_wait(sem2); dispatch_signal(sem1);}); dispatch_async(q, ^{dispatch_signal(sem2);}); this will deadlock if the pool size is 2 but work correctly with a larger pool (or with the workqueue implementation)