viboes wrote:
I mean that you want to intercept when a worker thread should have been blocked and process other tasks in the wait call:
void some_user_level_task() { ... some_future.wait(); // Do not really wait, execute other tasks using the same call stack ... }
Should this behaviour be extended to other synchronization functions like mutex lock, condition wait, ... ?
It is a very interesting idea, here are my thoughts; First of all, I think even doing work in future::wait is a little to automagic and think we should investigate if we can't make it explicit somehow. You probably do not want to do work while waiting for mutexes. They are only supposed to help synchronize and order operations, waiting is just a side effect of that. The idea of doing work while waiting on condition variables seems like a natural extension of doing the same for futures since futures also have the semantics of waiting for an event. Also, futures will most probably be built on top of condition variables. Perhaps some kind of policy with a default waiting behaviour; condition normal_condition_variable; condition<WorkWhileWaiting> cv; future<int> normal_future; future<int, WorkWhileWaiting> f; viboes wrote:
In addition the threadpool should provide a one step scheduling on the *current* worker thread.
There are certain subtle dangers with executing thread pool tasks belonging to other threads, but they might be acceptable if this behaviour is explicit (perhaps even if they aren't). IIRC, I discussed the matter with Peter Dimov here in boost.dev but can't seem to find the thread. Johan -- View this message in context: http://www.nabble.com/-threadpool--relation-with-TR2-proposal-tp19452045p195... Sent from the Boost - Dev mailing list archive at Nabble.com.