[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