[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