[cpp-threads] Asynchronous Execution Issues (caching_async)

Anthony Williams anthony at justsoftwaresolutions.co.uk
Sat May 2 20:59:06 BST 2009


At Sat 02 May 2009 02:22:15 BST, Peter Dimov <pdimov at mmltd.net> wrote:

> Boehm, Hans:
>> I think we're also clear on the fact that the suggested solutions   
>> are fairly drastic.  But I think the problems described in the   
>> paper are serious.  If we had reasonable alternatives, I'd prefer   
>> not to be suggest changes like this, especially at this stage.
>
> The problems are real (but, I'd argue, not of our creation; they exist
> no matter what we do or not do).

Agreed.

> Removing TLS destructors would also have interesting implications. It
> would force people to use pthread_key_create instead,

or simulate it with a global map<thread::id,some_type>

> and currently,
> pthread_join is not guaranteed (by the spec) to wait for the
> destructors to complete (whereas we would presumably require
> std::thread::join to wait until thread_locals are destroyed). So this
> both reintroduces the problem _and_ renders the proposed solution
> ineffective (at least in theory).

Yes.

> And if we pretend that TLS destructors don't exist in our threading
> model, we effectively say that appications using thread-specific
> storage in any nontrivial way should only create a fixed number of
> threads and only join them at process exit. Which basically rules out
> the "new thread" async.

Agreed.

> Incidentally, a function that destroys thread locals is also not a
> general solution since if one executes
>
>    X f();
>
> asynchronously, ~X has to run after the promise is set, and depending
> on X's allocator, may well return memory to a thread-specific free list.

Maybe it would be worth splitting the value-setting from making the  
future ready:

    promise::populate_value(X const&); // set the value, but don't  
trigger the future
    promise::make_ready(); // trigger the future, populate_value must  
already have been called

Then again this is what packaged_task is intended for, and can do this  
split internally, so maybe we should tighten up the wording to ensure  
this.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Custom Software Development         | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK





More information about the cpp-threads mailing list