Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-11-03 09:23:00

"Oliver Kowalke" <k-oli_at_[hidden]> writes:

>> >> 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*.
>
> What about this idea: instead of spawning a new thread still use fibers which will not migrated to other worker-threads.
> Nonblocking functionality of future::get() is moved into a public available function:
>
> template< typename Condition >
> void threadpool::yield( Condition cond)
> {
>   BOOST_ASSERT( tss_worker_.get() ); // only worker-threads allowed
>   while ( ! cond)
>     current_fiber_->yield(); 
> }

I really don't see what that gets you, except another potential
scheduling point: user code still has to actually use this in order to
allow rescheduling. There will always be threads that wait for
synchronization from elsewhere that don't use any mechanism you can
hijack to reschedule the pool (e.g. atomic ops on a boolean flag).

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK