[cpp-threads] Asynchronous Execution Issues
Oliver Kowalke
oliver.kowalke at gmx.de
Sat Apr 25 00:35:16 BST 2009
Am Saturday 25 April 2009 01:05:38 schrieb Lawrence Crowl:
> > - second item:
> > launch_in_thread() (== std::caching_async()) returns a
> > handle object which contain a smart pointer of boost::thread
> > (==std::thread). If the last instance of this handle gets out of
> > scope the custom destructor of smart pointer calls thread::join()
> > on the thread object (releasing the thread).
>
> And what happens to objects of thread storage duration?
Because I'm working on boost I assume that boost::thread_specific_ptr is used.
And the thread-local objects will then be cleaned up when the thread exits.
> > BTW handle allows to interrupt the task executed by the thread
> > and works as a async completion token (contains a future and
> > exposes this interface).
> >
> > - first:
> > launch_in_pool() would be equivalent to std::creating_async()
> > passing the task into a threapool and returning a handle object
> > too. But destroying a pool-internal-thread is not permitted. In
> > this case cleaning up thread-local data (thread_specific_ptr) after
> > execution of a task is a problem. Currently it is up to the user.
>
> Hm. Is the mapping reversed? In my proposal, the caching_async
> need not join after completion, but may place the thread in a pool
> for reuse later.
The worker threads in the pool are pre-forked and managed by the pool.
The handle created by a task which is executed in a pool doesn't join the
worker-thread (this is different from a launch_in_thread() where a new thread
gets joined by the handle).
Worker threads are joined only by the owning pool (destructor or explicit by
pool::shutdown()).
> > Am Friday 24 April 2009 22:39:11 schrieb Lawrence Crowl:
>
> Hm. Your mailer seems incompletely localized. Shouldn't that
> be Freitag?
Well I didn't noticed this - thx (I've to look what's wrong).
best regards,
Oliver
More information about the cpp-threads
mailing list