interrest in a thread-pool library
Hi, I follow the discussion about boost.future since the review request form Braddock. I'm using Braddocks future implementation for my threadpool library - may you are interessted in (I've uploaded two versions in the boost vault/Concurrent Programming). The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). I've uploaded two versions. In version 1 a future is returned by submit of a task. Canceling the future means removing the task form the channel if it is still pending. Version 2 returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ). Oliver
Hi! I'm very interested in your threadpool Lib. I will take a look at it as soon as possible.Would you say it's stable for production use? Greetings Manuel Jung k-oli@gmx.de wrote:
Hi, I follow the discussion about boost.future since the review request form Braddock. I'm using Braddocks future implementation for my threadpool library - may you are interessted in (I've uploaded two versions in the boost vault/Concurrent Programming).
The library provides:
- thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time
- channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads
- queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)
- tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library).
I've uploaded two versions.
In version 1 a future is returned by submit of a task. Canceling the future means removing the task form the channel if it is still pending.
Version 2 returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ).
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am Donnerstag, 12. Juni 2008 23:51:13 schrieb Manuel Jung:
Hi!
I'm very interested in your threadpool Lib. I will take a look at it as soon as possible.Would you say it's stable for production use? Greetings Manuel Jung
In my app it works but with multithreaded applicatioons you can encounter surprises :) I would feel better if some of you could review the code and testing by other people would also help. regards, Oliver
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of k-oli@gmx.de Sent: Wednesday, June 11, 2008 10:21 PM To: boost@lists.boost.org Subject: [boost] interrest in a thread-pool library
Hi, I follow the discussion about boost.future since the review request
Braddock. I'm using Braddocks future implementation for my threadpool library - may you are interessted in (I've uploaded two versions in the boost vault/Concurrent Programming).
The library provides:
- thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time
- channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer
How would you say your thread-pool libraries compare with Philipp Henkel's threadpool library [<http://threadpool.sourceforge.net/>]? Moshe form threads
- queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)
- tasks can be chained and lazy submit of taks is also supported
(thanks
to Braddocks future library).
I've uploaded two versions.
In version 1 a future is returned by submit of a task. Canceling the future means removing the task form the channel if it is still pending.
Version 2 returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ).
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
My implementations are more influenced by the java threadpool design. I took a quick look at the library from Philipp Henkel and I can say only what's different. Please keep in mind that my assumptions about Phillips lib may be wrong: - In Philipps library the pool is resized by the user. In my libs the threads are managed by the pool itself (at least the adaptive pool lets increase and decrease the worker threads depending on the idle time). - Philipps lib contains a future but doesn't use it. At least the pool::schedule function only returns a boolean. In my libs a future or a task object (containing a future) is returned. So the chaining or the lazy evaluation of tasks is only supported my my proposal. - My libraries allow to cancel the submitted task (v1 - cancel the future == remove it from the queue; v2 - interrupt task == remove task from queue or interupt running task) - My lib provides bounded and unbounded queues (bounded queue == limiting the number of pending tasks). The rendezvous channel may be of limited use. - I also provide a possibility for smart queuing which influences how task inserted and extracted from the channel (allows for instance to replace old pending task be new one). Oliver -------- Original-Nachricht --------
Datum: Tue, 24 Jun 2008 16:20:57 +0300 Von: "Moshe Matitya" <Moshe.Matitya@Kayote.com> An: boost@lists.boost.org Betreff: Re: [boost] interrest in a thread-pool library
How would you say your thread-pool libraries compare with Philipp Henkel's threadpool library [<http://threadpool.sourceforge.net/>]?
Moshe
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of k-oli@gmx.de Sent: Wednesday, June 11, 2008 10:21 PM To: boost@lists.boost.org Subject: [boost] interrest in a thread-pool library
Hi, I follow the discussion about boost.future since the review request form Braddock. I'm using Braddocks future implementation for my threadpool library - may you are interessted in (I've uploaded two versions in the boost vault/Concurrent Programming).
The library provides:
- thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time
- channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads
- queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)
- tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library).
I've uploaded two versions.
In version 1 a future is returned by submit of a task. Canceling the future means removing the task form the channel if it is still pending.
Version 2 returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ).
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
participants (4)
-
k-oli＠gmx.de -
Manuel Jung -
Moshe Matitya -
Oliver Kowalke