[cpp-threads] Thread API interface tweaks

Howard Hinnant hinnant at twcny.rr.com
Mon Aug 28 17:11:04 BST 2006


On Aug 27, 2006, at 3:09 PM, Peter Dimov wrote:

> Cancellation complicates matters a bit, and so does "multiple wait"
> support, and I haven't implemented these yet.

I like the idea of a completely layered approach that is non- 
intrusive of the thread (single owner) model.  Indeed this is what I  
was trying to implement.  But I haven't figured out how to implement  
it yet.  Specifically the "multiple wait", or even really the "single  
wait", has me stumped for the moment.  I studied your outline but  
don't yet understand how a future can be created, linked to the  
return value of a thread, but still have the choice of blocking on it  
or not (and be copyable).

It seems to me that the start function of the thread must somehow  
notify those waiting for it to complete.  In pthreads I see two  
mechanisms to do this with:

1.  Waiting thread calls pthread_join:  Only one thread can do this.   
There is no try_pthread_join.  Must have pthread_t (id) to make this  
call.

2.  Have the start function call notify_all() on a condition variable  
(just before thread-end) which other threads can wait on.

(I know this language is posix-specific, but I believe Windows has  
similar functionality.  I'm counting on Windows experts to keep me  
portable here.)

My current thinking is that thread<R> would use (1) and future<R>  
would use (2).

I'm also thinking that philosophically, future<R> does not own the  
thread of execution in any manner, but is simply a copyable view of  
the thread's return value.  And since that view can change  
asynchronously, there must be some way for the futures to tell if a  
valid return value has yet been written.

Conversely, thread<R> owns the thread of execution (uniquely).  From  
here you can control the thread of execution in whatever ways might  
be possible (On Mac this would include cancel, detach, join, get/set- 
schedparam, get stack size and location, kill it, or signal it --  
most of these via OS-specific calls).

-Howard




More information about the cpp-threads mailing list