[thread] cache of initialized threads
Hi, When we have to create lot of threads dynamicaly it will be better to have a 'pool' of initialized threads (the initialization of a thread takes significant time). Please not that this has nothing to be with the thread_pool class. I'm looking for any work done related to this problem (libraries, emails, ...). Any hints or comments? Thanks in advance Vicente My first thoghts: The cached_threader class interface could be something like class cached_thread; class cached_threader { public: cached_thread launch(boost::function<void()>&); private: friend class cached_thread; void restore(cached_thread); } cached_thread will provide most of the boost::thread operation but some as detach seams not adapted. class cached_thread { friend class cached_threader; cached_threade launch(boost::function<void()>& f); public: cached_thread(); ~cached_thread(); // move support cached_thread(detail::thread_move_t<thread> x); cached_thread& operator=(detail::thread_move_t<cached_thread> x); operator detail::thread_move_t<cached_thread>(); detail::thread_move_t<cached_thread> move(); void swap(cached_thread& x); // ... } The destructor has the responsability to restore the cached_thread to its cached_threader pool. _____________________ Vicente Juan Botet Escriba
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
When we have to create lot of threads dynamicaly it will be better to have a 'pool' of initialized threads (the initialization of a thread takes significant time). Please not that this has nothing to be with the thread_pool class.
If this isn't for worker threads in a thread pool, what is the purpose? Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Thursday, May 08, 2008 4:47 PM Subject: Re: [boost] [thread] cache of initialized threads
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
When we have to create lot of threads dynamicaly it will be better to have a 'pool' of initialized threads (the initialization of a thread takes significant time). Please not that this has nothing to be with the thread_pool class.
If this isn't for worker threads in a thread pool, what is the purpose?
Well, both classes respond similar goals. The differences are much more related to when the function is called and the interface provided by the result of the request. Imagine I have in my code a lot of threads that are created/destroyed dynamicaly. For performances purposes I decide to creates this threads using a thread factory which caches some idle threads instead of destroying them. Whay I want is to preserv as much as possible the interface, so the result of the thread factory must conform as much as possible to the thread interface. Note that may initial application had not the notion of thread group. The thread_pool I have used so far calls the function asynchronously, because the function will be stored on the queue of pending. With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one. In addition a cached thread should behaves as much as possible as a thread. A thread_pool is much more a multi_task scheduler than a thread factory. Maybe a thread_pool with the needed policies can give the same result. Why not? . Task type : provide the thread functionality . Scheduling Policy : immediate (Synchronous) . Size Policy creates a new one when no more available Do you know a thread_pool library allowing to implement the required behaviour? Thanks _____________________ Vicente Juan Botet Escriba
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
If this isn't for worker threads in a thread pool, what is the purpose?
Imagine I have in my code a lot of threads that are created/destroyed dynamicaly. For performances purposes I decide to creates this threads using a thread factory which caches some idle threads instead of destroying them. Whay I want is to preserv as much as possible the interface, so the result of the thread factory must conform as much as possible to the thread interface. Note that may initial application had not the notion of thread group.
The thread_pool I have used so far calls the function asynchronously, because the function will be stored on the queue of pending. With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one.
OK. That makes sense.
In addition a cached thread should behaves as much as possible as a thread. A thread_pool is much more a multi_task scheduler than a thread factory.
Maybe a thread_pool with the needed policies can give the same result. Why not? . Task type : provide the thread functionality . Scheduling Policy : immediate (Synchronous) . Size Policy creates a new one when no more available
Do you know a thread_pool library allowing to implement the required behaviour?
No, sorry. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi vincent, 2008/5/8 vicente.botet <vicente.botet@wanadoo.fr>:
In addition a cached thread should behaves as much as possible as a thread. A thread_pool is much more a multi_task scheduler than a thread factory.
Maybe a thread_pool with the needed policies can give the same result. Why not? . Task type : provide the thread functionality . Scheduling Policy : immediate (Synchronous) . Size Policy creates a new one when no more available
Do you know a thread_pool library allowing to implement the required behaviour?
http://sourceforge.net/projects/threadpool It looks like it's still being maintained. I've never really used it for anything proper, but it seems to do some of the things you're looking for. Regards, Darren
----- Original Message ----- From: "Darren Garvey" <darren.garvey@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, May 08, 2008 5:57 PM Subject: Re: [boost] [thread] cache of initialized threads
Hi vincent,
2008/5/8 vicente.botet <vicente.botet@wanadoo.fr>:
In addition a cached thread should behaves as much as possible as a thread. A thread_pool is much more a multi_task scheduler than a thread factory.
Maybe a thread_pool with the needed policies can give the same result. Why not? . Task type : provide the thread functionality . Scheduling Policy : immediate (Synchronous) . Size Policy creates a new one when no more available
Do you know a thread_pool library allowing to implement the required behaviour?
http://sourceforge.net/projects/threadpool
It looks like it's still being maintained. I've never really used it for anything proper, but it seems to do some of the things you're looking for.
Thanks Darren, I'll take a look to see if I can use it. _____________________ Vicente Juan Botet Escriba
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Thursday, May 08, 2008 8:51 PM Subject: Re: [boost] [thread] cache of initialized threads
----- Original Message ----- From: "Darren Garvey" <darren.garvey@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, May 08, 2008 5:57 PM Subject: Re: [boost] [thread] cache of initialized threads
Hi vincent,
2008/5/8 vicente.botet <vicente.botet@wanadoo.fr>:
In addition a cached thread should behaves as much as possible as a thread. A thread_pool is much more a multi_task scheduler than a thread factory.
Maybe a thread_pool with the needed policies can give the same result. Why not? . Task type : provide the thread functionality . Scheduling Policy : immediate (Synchronous) . Size Policy creates a new one when no more available
Do you know a thread_pool library allowing to implement the required behaviour?
http://sourceforge.net/projects/threadpool
It looks like it's still being maintained. I've never really used it for anything proper, but it seems to do some of the things you're looking for.
Thanks Darren,
I'll take a look to see if I can use it.
Hi Darren, this is an interesting thread pool library, but I think that the main problem concerning my use case is that the schedule function do not returns a hadle to the thread that takes/will take in account the task, and so I have no mean to interrupt the task, join the task, and so one. I will look more deeply in the implementation to see if I can make some adaptations to reach my goals. Thanks again for the link. Has someone else other pointers? _____________________ Vicente Juan Botet Escriba
Darren Garvey <darren.garvey <at> gmail.com> writes:
Hi vincent,
2008/5/8 vicente.botet <vicente.botet <at> wanadoo.fr>:
Do you know a thread_pool library allowing to implement the required behaviour?
http://sourceforge.net/projects/threadpool
It looks like it's still being maintained. I've never really used it for anything proper, but it seems to do some of the things you're looking for.
I used it for a parallelized merge-sort on linux GCC 4.1.2. Worked fine. Would like to see it in boost. Joel
With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one.
I suspect it's not going to help you much, but this is how the native thread pool behaves on Windows. Jim ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
----- Original Message ----- From: "James Talbut" <James.Talbut@omg3d.com> To: <boost@lists.boost.org> Sent: Friday, May 09, 2008 9:39 AM Subject: Re: [boost] [thread] cache of initialized threads
With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one.
I suspect it's not going to help you much, but this is how the native thread pool behaves on Windows.
Hi Jim, I don't know Windows at all. This is a good new, we will need only to implement it for posix threads. Could you give me some pointers? Thanks, Vicente
The Windows Threadpool (from Vista onwards) has quite a lot of features and is very usable, unfortunately prior to Vista it was much more limited and couldn't do tracking of job completion well. Using the threadpool involves a lot of functions calls, mainly for initialising static data (you create a structure and pass it to the function to init). The starting point is here: http://msdn.microsoft.com/en-us/library/ms682456.aspx (though you don't actually have to create a threadpool yourself because there is a default). When a job is submitted and the pool is busy it 'may' create a new thread, depending on a private algorithm. You use SetThreadpoolCallbackRunsLong to influence this. Bearing in mind that thread creation is expensive (potentially much more so than simply completing a callback) you don't want to use a naiive implementation that always creates new threads (unless you know your jobs are big, which a library can't know). Obviously, being as they are Windows functions they aren't C++ specific - the job function has a fixed signature taking a PVOID, for example. If you need to support Windows and pthreads I wouldn't use the windows threadpool, coming up with a suitable abstraction won't be simple - I'd go for something built on top of boost::threads. See here for a sample: http://msdn.microsoft.com/en-us/library/ms686980(VS.85).aspx HTH. Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of vicente.botet Sent: 09 May 2008 09:48 To: boost@lists.boost.org Subject: Re: [boost] [thread] cache of initialized threads
----- Original Message ----- From: "James Talbut" <James.Talbut@omg3d.com> To: <boost@lists.boost.org> Sent: Friday, May 09, 2008 9:39 AM Subject: Re: [boost] [thread] cache of initialized threads
With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one.
I suspect it's not going to help you much, but this is how the native thread pool behaves on Windows.
Hi Jim,
I don't know Windows at all. This is a good new, we will need only to implement it for posix threads.
Could you give me some pointers?
Thanks,
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
----- Original Message ----- From: "James Talbut" <James.Talbut@omg3d.com> To: <boost@lists.boost.org> Sent: Friday, May 09, 2008 11:01 AM Subject: Re: [boost] [thread] cache of initialized threads
The Windows Threadpool (from Vista onwards) has quite a lot of features and is very usable, unfortunately prior to Vista it was much more limited and couldn't do tracking of job completion well. Using the threadpool involves a lot of functions calls, mainly for initialising static data (you create a structure and pass it to the function to init). The starting point is here: http://msdn.microsoft.com/en-us/library/ms682456.aspx (though you don't actually have to create a threadpool yourself because there is a default).
When a job is submitted and the pool is busy it 'may' create a new thread, depending on a private algorithm. You use SetThreadpoolCallbackRunsLong to influence this. Bearing in mind that thread creation is expensive (potentially much more so than simply completing a callback) you don't want to use a naiive implementation that always creates new threads (unless you know your jobs are big, which a library can't know).
What the user will do if there is no more idle threads if the thread pool do not create it implicitly? May be resize the pool? Yes, this is not a bad idea, the user could request this creation explicitly with one specific parameter. cached_thread thread_factory::make(Callable& fct); cached_thread thread_factory::make(Callable& fct, force_creation_t&);
Obviously, being as they are Windows functions they aren't C++ specific - the job function has a fixed signature taking a PVOID, for example. If you need to support Windows and pthreads I wouldn't use the windows threadpool, coming up with a suitable abstraction won't be simple - I'd go for something built on top of boost::threads.
Yes, you are right when writing a library on top of the boost thread library. The question should not have the same answer if it the thread library will includes this thread factory. Do you think that it would be interesting to use this native thread pool in this case? Thanks for all Vicente
See here for a sample: http://msdn.microsoft.com/en-us/library/ms686980(VS.85).aspx
HTH.
Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of vicente.botet Sent: 09 May 2008 09:48 To: boost@lists.boost.org Subject: Re: [boost] [thread] cache of initialized threads
----- Original Message ----- From: "James Talbut" <James.Talbut@omg3d.com> To: <boost@lists.boost.org> Sent: Friday, May 09, 2008 9:39 AM Subject: Re: [boost] [thread] cache of initialized threads
With a thread cache either the threre is a cached_thread in the pool and we use it to launch the user function, either the chached_threader will crate a new one.
I suspect it's not going to help you much, but this is how the native thread pool behaves on Windows.
Hi Jim,
I don't know Windows at all. This is a good new, we will need only to implement it for posix threads.
Could you give me some pointers?
Thanks,
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
When a job is submitted and the pool is busy it 'may' create a new thread, depending on a private algorithm. You use SetThreadpoolCallbackRunsLong to influence this. Bearing in mind that thread creation is expensive (potentially much more so than simply completing a callback) you don't want to use a naiive implementation that always creates new threads (unless you know your jobs are big, which a library can't know). What the user will do if there is no more idle threads if the thread pool do not create it implicitly? May be resize the pool?
No, the user has no access to the actual size of the pool. Jobs are simply queued until there is an available thread to service them. New thread creation is based on the length of the queue and whether callbacks are expected to run for a long time.
Yes, this is not a bad idea, the user could request this creation explicitly with one specific parameter.
cached_thread thread_factory::make(Callable& fct); cached_thread thread_factory::make(Callable& fct, force_creation_t&);
The closest you have is SetThreadpoolCallbackRunsLong.
Yes, you are right when writing a library on top of the boost thread library. The question should not have the same answer if it the thread library will includes this thread factory. Do you think that it would be interesting to use this native thread pool in this case?
Oh it would probably be interesting :) The problem is that, if you intend to support pthreads and Windows, you need to write an abstraction layer over the Windows threadpool that also suites the threadpool that you have to write/obtain for pthreads - and I don't think that would be very easy (though I haven't tried writing a thread-safe resizable threadpool using pthreads). Jim ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
participants (5)
-
Anthony Williams -
Darren Garvey -
James Talbut -
Joel -
vicente.botet