[cpp-threads] Thread try/time_join (was: Asynchronous Function Proposal)

[Howard Hinnant]

On Jun 2, 2009, at 6:08 PM, Herb Sutter wrote:

>>> Could someone please refresh my memory as to why try_join and
>>> timed_join were not included? Was it a lack of motivating use cases?
>>
>> For my money it is because of lack of those functions in the posix
>> API.  I.e. I'd like to layer std::thread as thinly as possible over
>> what my OS offers, which is pthreads.  Adding try/time_join into
>> higher level layers (such as future) doesn't bother me at all because
>> one is already into thicker layers (auxiliary heap storage) by then.
>
> Are you opposed to adding a couple of functions to thread that  
> aren't in every threading API? Just because it's not part of core  
> pthreads doesn't mean we shouldn't fill a gap and provide a complete  
> interface, right? (I promise not to mention the C-word here.)

My concern is that not everyone needs try/timed join, but if we put  
this functionality into the base level API, then everyone will pay for  
it via higher overhead and lower performance.  I will effectively have  
to duplicate pthreads functionality on top of pthreads.  This isn't  
terribly hard.  One needs to do it for futures anyway (for example).   
But it means that std::thread is no longer a thin wrapper over  
pthread_t.  As soon as this happens there is a significant performance  
motivation for my customers to use pthreads instead of std::thread.

On Jun 3, 2009, at 11:01 AM, Bjarne Stroustrup wrote:

> We should remember that we are not trying to design and standardize  
> a parallel programming system/library; we are trying to provide a  
> primitive mechanism to allow others to build such libraries/systems.
>
> Trying to provide a complete high-level parallel programming library  
> is not just beyond us in the time available and (IMO) premature, but  
> also against our agreement on how to proceed (spend our precious  
> little time) "the Kona compromise." To contrast, I consider  
> providing a mechanism, async(), both feasible and within the Kona  
> compromise. Kudos to Lawrence for taking the initiative.

Exactly.

I've been trying (rather unsuccessfully) for years to argue that we  
need a layered solution.  The bottom layer should be as thin and  
efficient as possible so that it is practical to build many fuller  
featured layers on top of it.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html

> To represent an OS thread, a simple (low-level), thread class is  
> introduced. This class is designed to be as thin a layer over the OS  
> thread as possible. After all,task's, future's, and possibly user- 
> defined abstractions will be built on top of thread and thus all  
> overhead is significant.

If we can't do it with a layout that looks like:

class thread
{
     pthread_t id_;
public:
     ...
};

then it doesn't belong in the lowest level API.

Yes, we do want try and timed join functionality.  And we want lots of  
other useful features as well.  But we do not want it in the lowest  
layer.  We want it such that people who need it can choose to pay for  
it, and people that don't need it can choose not to pay for it.

Building the ultimate std::thread, with all the bells and whistles  
anyone wants, would be second biggest mistake we could make for  
std::thread.  The very biggest mistake will remain jettisoning  
interruption (or however you want to spell cancellation).  Indeed,  
perhaps it won't really matter.  I fully expect Scott Meyers to  
recommend boost::thread over std::thread anyway.  As it stands today,  
that's what I would recommend too.

http://www.boost.org/doc/libs/1_39_0/doc/html/thread.html

-Howard