Boost logo

Boost :

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
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



Boost list run by bdawes at, gregod at, cpdaniel at, john at