[cpp-threads] Re: Thread API interface tweaks
Lawrence Crowl
lawrence.crowl at gmail.com
Wed Aug 30 23:19:08 BST 2006
> On Aug 29, 2006, at 5:00 PM, Lawrence Crowl wrote:
> > The distinction between class thread and class thread_id seems
> > excessively
> > complex. Why should we have thread at all? Why not just thread_id?
> > The storage can be deallocated after completion of the join operation,
> > which is essentially equivalent to new/delete.
On 8/29/06, Howard Hinnant <hinnant at twcny.rr.com> wrote:
> The motivating use case for me came while trying to implement a
> recursive_mutex adaptor (similar in spirit to a std::stack or
> std::queue - container adaptors). It looks something like:
....
> I.e. recursive_mutex<Mutex> takes any exclusive Mutex and turns it
> into a recursive mutex. To implement this I needed the notion of
> thread id. But thread, which can refer to exclusive ownership of a
> thread of execution, and which may need to contain more data than a
> simple id, is overkill for this application.
I should have been more clear. I'm not questioning the need for thread_id,
but the need for a user-exposed thread (as you have named and implemented
them.) I don't think making this type visible actually buys much.
> On Aug 29, 2006, at 5:00 PM, Lawrence Crowl wrote:
> > Futures are a very valuable facility, too valuable to be tied to
> > threads.
> > They should be a separate facility that happens to also work with
> > threads.
>
> That sounds very interesting to me. Got a prototype? I'll start
> working, but I don't trust myself to correctly implement this
> suggestion. It would be good to have more than one prototype to look
> at.
I'll take a look. The idea only came to me during Herb's talk.
> On Aug 29, 2006, at 5:00 PM, Lawrence Crowl wrote:
> > We already have a keyword __thread, and I think that defining a type
> > named thread will lead to confusion. The joiner terminology at least
> > does not have that problem.
>
> Agreed. Although I'm not as sure of the resolution. We could rename
> either __thread or thread. E.g. __thread_local.
Yes, though I note that __thread is already in compilers and programs.
--
Lawrence Crowl
More information about the cpp-threads
mailing list