Re: [boost] boost::defer - generalised execution deferral

From: Oliver.Kowalke_at_[hidden]
Date: 2005-12-05 06:41:40

Hello Simon,
it's a nice implementation. 
Maybe you could add a timed enqueue and dequeue and a limitation
(amount) for the work items in the queue. I could use the implementation
form thread_queue in the same sandbox folder.
With regards,
Oliver

>a second version of library Defer is now in the sandbox under
Concurrent
>Programming.
>(this version primarily adds the promised win32 message pump version)
>
>To recap - this library defines a uniform means to send work items
>(boost::function objects) to thread pools, single threads and the
windows
>gui thread
>via a runtime polymorphic interface.
>
>Other implementations of the defer concept included in the library are
>defer_null, which
>makes no attempt to defer, but invokes the supplied boost::function
object
>immediately
>and defer_mutex, which also invokes the object on the calling thread,
but
>only after first
>acquiring a mutex (thus serialising requests from different threads).
>
>The benefits of such a library are:.
>-It allows an efficient reuse of threads.
>-It provides an abstract way to parameterise threading architecture
i.e.
>-It allows the programmer to define what thread s/he wishes to
>receive callbacks in from cooperating components.
>-It can be used to eliminate thread deadlocking issues, and remove
>mutex use from much application code.
>-It can help break recursive calling cycles in event driven code.
>
>The scheme is wide open for the addition of more models of the defer
>concept.
>The base defer class provides the queue facilities, and simply requires
the
>deriving classes to implement a 'signal' function, in which to perform
an
>implementation specific wakeup or notification to the appropriate
thread.
>
>Three examples of possible other styles are:
>-demuxer style thread parking - create the object and then call a run()
>function in
>an appropriate thread
>-recursion breaking - first defer in a given thread executes
immediately,
>subsequent
>recursive defers on the same object are queued to be serviced in turn
>before
>the thread finally leaves the object
>-thread creating - creates an entirely new thread per work item.
>
>All comments again welcome, though I know its a busy time for boosters
with
>the
>huge effort going into the next release.
>
>Cheers
>
>Simon
>
>
>
>_______________________________________________
>Unsubscribe & other changes:
>http://lists.boost.org/mailman/listinfo.cgi/boost