Am Mittwoch, 16. Juli 2008 15:06:57 schrieb vicente.botet:

I'm not saying that your thread_pool library is not useful, but IMO we need both.

As I wrote in the documentation - the lib deals only with independed tasks (the FJ related usage is out of scope).

When you implement with your thread_pool library the following common parallel algorithm Result solve(Problem problem) {

if (problem is small)

directly solve problem

else {

split problem into independent parts

fork new subtasks to solve each part recursively

join all subtasks

compose result from subresults

}

}

I did a look into FJ and I found it not so useful for non cpu-intensive tasks: The main tasks (submited to the FJ classes; creating subtasks) are processed notin parallel. That means one main-taks is taken from the queue by a worker thread, the sub-tasks are stolen by other worker tasks and then if all sub-tasks are joined the next main-tasks is dequeued. (I debugged the fork-join implementation of Doug Lea)

you will need a number of threads that depend on the depth of the sub-task tree because the thread executing a task is blocked waiting for its sub-tasks. If we have a limited number of threads we will be unable to solve the general problem, If the number is dynamic your library can create a number of threads that can exhaust the memory.

This would violate the concept of my lib - threads are limited resources and therefor each pool as a upper limit of worker threads.

With the FJ framework you only need a thread, and usually you use the same number of threads that the number of processors or cores.

FJ seams to be more related to computation intensive tasks.

Then even if your thread_pool is useful to schedule task that do not wait (on sub-tasks), we need also a thread_pool based on the ideas of the FJ framework or the TBB Task scheduler toimplement some parallel algorithms.

I did not found a high usage of the FJ concept. Most ofthe algorithms could also be implemented non-recursively. The example usualy provided by FJ libraries is the recursive fibonacci calculation. Fibonacci numbers could be implemented more performant in a non-recursive manner. Oliver

Hello Ronald, I#ve added a new version of thread_pool to the vault(boost-threadpool.3.tar.gz: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-threadpool.3.tar.gz&directory=Concurrent%20Programming&). Could you please so kind to change the link in the review schedule page? I'm also not able to remove the old version from the vault - I get an HTTP-Error 404? if I click on the red cross! Thanks in advance, Oliver Am Donnerstag, 17. Juli 2008 17:39:23 schrieb Ronald Garcia:

Hi Oliver,

I have added your library to the review queue as requested.

Cheers, ron

On Jul 15, 2008, at 1:13 PM, Oliver Kowalke wrote:

...

Hello, I'd like to request a review of my thread_pool library - it is available at 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).

- 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 -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/616 9196 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hello Ruediger, would you take over the review manager part? regards, Oliver Am Donnerstag, 11. September 2008 18:31:58 schrieb Ruediger Berlich:

Hi there,

I'd just like to indicate my strong interest in a formally reviewed threadpool library for boost. Hence I'd be happy to participate in a review on the reviewer side. Let me know if/when this is of interest.

Best Regards, Ruediger Berlich

k-oli@gmx.de wrote:

...

Hello Ronald, I#ve added a new version of thread_pool to the vault(boost-threadpool.3.tar.gz:

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost- threadpool.3.tar.gz&directory=Concurrent%20Programming&).

...

Could you please so kind to change the link in the review schedule page? I'm also not able to remove the old version from the vault - I get an HTTP-Error 404? if I click on the red cross!

Thanks in advance, Oliver

Am Donnerstag, 17. Juli 2008 17:39:23 schrieb Ronald Garcia:

...

Hi Oliver,

I have added your library to the review queue as requested.

Cheers, ron

On Jul 15, 2008, at 1:13 PM, Oliver Kowalke wrote:

...

Hello, I'd like to request a review of my thread_pool library - it is available at 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).

- 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 -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!

http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/616

...

...

...

9196 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am Freitag, 12. September 2008 16:23:00 schrieb Ruediger Berlich:

Hi Oliver,

k-oli@gmx.de wrote:

...

Hello Ruediger, would you take over the review manager part? regards, Oliver

I realize that finding the review manager must be the hardest part ...

... but, as so far I didn't participate in any Boost reviews at all, I feel that it would be inappropriate for me to become the review manager. As I said, I'm more than happy to contribute to the review itself, though.

OK

My suggestion would be to talk to Anthony Williams as one of the authors of the thread library and to ask him whether he'd be willing to act as the review manager. I would strongly assume that the integration of a threadpool library into Boost would shape Boost thread programming a lot.

Anthony has also a threadpool proposal in TR2.

But probably all of this will have to wait until a review manager for the Futures library/ies has been found, as your library depends on it ?

Because two future libs are scheduled for review - threadpool can influence the review of both libs?! Maybe a review of future and threadpool would make sense?

Sorry and Best Regards, Ruediger

Oliver