Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-03 08:08:43

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 03, 2008 12:09 PM
Subject: Re: [boost] [threadpool] new version v12

> "Oliver Kowalke" <k-oli_at_[hidden]> writes:
>> But what about executing fibered tasks only in the worker-thread
>> which has created the fiber?
>
> There is still a problem (just different).
>
>> Then a new task is dequeued from the local worker-queue, then from
>> the global -queue and then from worker-queues of other threads.
>
> Here's the problem: if you take a task from the global queue or the
> worker queue of another thread and *don't* do thread migration, then
> you risk delaying a task and potentially deadlocking the pool.
>
> Consider the sequence above: at step 5, task A is blocked, and the
> only task it is waiting for (B) has been picked up by an idle worker
> thread. The thread running task A now takes a new task from the global
> queue (task N). Suppose this is a really long-running task (calculate
> PI to 3 million digits, defrag a hard disk, etc.). Without thread
> migration, task A cannot resume until task N is complete.
>
> Obviously, if task N blocks on a future you can then reschedule task
> A, but if it doesn't then you don't get that opportunity. If task N
> waits for another event to be triggered from task A (e.g. a notify on
> a condition variable) then it will never get it because task A is
> suspended, and so the pool thread will deadlock *even when task A is
> ready to run*.

Obiously this sequence justify that a task could need to migrate to another 
thread.
It seems that task scheduling is not as easy as I thought.

Thanks for draw forth this issue.

Vicente