[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