[boost] boost::defer - generalised execution deferral

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-11-25 18:05:17

"Any interest in...?"

This post asks the above question in relation to a possible library 
boost::defer which would live
half-way between the Herb Sutter active/future thread model and the semi-raw 
facilities of boost::thread.

Deferral here means
1. Do something later
2. Let something else decide which thread will execute the work

Facilities like boost::function offer a way to wrap up a unit of work that 
can be deferred. (UOW)

boost::defer would offer a way of posting the work unit to a Defer Point 
object that would call the unit of work
in whatever is the appropriate thread. The Defer Point acts as a queue for 
scheduled work items

Different polymorphic styles of Defer Point would implement different 
strategies for which kind of thread does the callback
1. single thread - owned by the Defer Point
2. Pool - staic or dynamic pool of threads owned by the Defer Point
3. win32 hidden window (dispatches callback on a gui thread)
4. NULL - Calling thread callback (i.e. do it now in the caller's thread)
5. Gating - Calling thread with mutex protection (serializes multiple 
threads thus protecting the called code)

Any given defer point object can either be dedicated to a particular task, 
or can be shared throughout
a program giving rise to a variety of ways of using system threads

1. One single thread defer point, reused throughout a program -> cooperative 
multi-tasking
2. win32 hidden window reused throughout -> cooperative multi-tasking on the 
gui thread
3. as above, but with another dedicated thread Defer Point (or pool) used 
for slow background tasks

I've found these threading concepts to be useful in large-scale projects 
where multiple libraries want to
do callbacks into some application code. Defer Points allow you to 
parameterise those libraries in
such a way as to play nicely with eachother - deferring their callback 
strategy to a style defined
by the programmer integrating the libraries into the final app.

Its also handy where multiple entities in a program need to call into 
eachother, potentially recursively
(A calls B calls A calls B) Better to break this recursion with queues of 
work items.

So - any interest in more concrete code? More detailed explanations and 
scenarios?

Cheers

Simon