Re: [boost] Re: Redesigned thread class

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-28 13:50:37

From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> >(POSIX-based) refers to the fact that the implementation is POSIX-based.
>
> This just further confuses things for me.  I thought you were laying out 5
> different design approaches.

No, these were implementation variations of a single specification:

"The behavior of current() when called from a thread that has not been
created by the library and is not the main thread is implementation
defined."

> >Fully compliant current() means that it produces a reference to a
> >full-featured thread object, as if the thread has been created by the
> >library.
>
> Options #2 and #3 produce "fully compliant current()" by this definition.
> OK, to be fair you're referring to the restriction on not being able to
> "join" such objects, but I do not consider this to be as severe as you
seem
> to.

Exactly. There is one more thing to a 'fully compliant' current() - it has
to return a reference to the same thread object (if the design exposes a
thread object, of course) when invoked several times from the same thread -
but I believe this is solvable.

> OK, I misunderstood what you meant in your description of #2.  #2 is
> pointless and basically impossible to do.

Probably right.

> >I don't quite understand. Why should a thread_ref use "wait" >semantics?
As
> >I
> >said, thread_ref join is exactly equivalent to boost::thread::join.
>
> That's an implementation impossibility for "adopted" threads.

I still don't understand.

typedef shared_ptr<boost::thread> thread_ref;

void join(thread_ref r)
{
    r->join();
}

What is impossible about it? join(thread_ref) has exactly the same semantics
as boost::thread::join, however it is defined. When boost::thread::join
joins, so does thread_ref. When it waits, thread_ref waits too.

> For threads
> that were not adopted you can give true "join" semantics, but this is true
> for both POSIX and Boost.Threads base implementations for a thread_ref
> concept.  Now, once standardized it will be theoretically possible for
> implementations to give true "join" semantics even for adopted threads
since
> the implementations can take advantage of platform details that we do not
> have access to in POSIX (and that's already the norm in Win32).  But at
this
> stage we're strictly talking about implementations based on top of POSIX
and
> Win32 constructs, and it's simply not possible to create a thread_ref with
> "join" semantics on top of POSIX.

Perhaps you mean that a thread_ref returned by current() when called from an
adopted thread can't have "join" semantics, in which case I agree that this
requires support from the pthreads implementation.

> Now, a valid decision would be to use "join" semantics for any thread
> created by the library and "wait" semantics for those that are adopted.  I
> see only a few small holes in doing this, and they are not likely to be
real
> issues for any actual uses.  This is the route I'd go, and the
Boost.Threads
> proposed design does not hinder you from doing this.

Except for the default-constructed thread object validity across threads and
the main thread issue, yes.

We are finally starting to understand each other. ;-) Although I have a
feeling that we'll revisit most of this when additional functionality is
added.

Just to clarify: what does boost::thread::join() do when called on an
adopted thread? What does it do when called a second time on a
library-created thread? I tried to look at thread.html in the cvs but I
think it's obsolete.

> I've got two comments about this.  First, Boost.Threads isn't a part of
the
> language.

Yet. And if you (we) don't design it to be suitable for inclusion, it will
never be.

> We have to make some decisions and choices that a standards
> endorsed library would not, simply because they can accomodate such things
> with changes to the abstract machine. The goal of Boost.Threads is to
> document such areas with the hope that the standards committee can address
> the abstract machine issues and change the library requirements
accordingly.

I agree, however I don't see how the abstract machine affects the
adoption/joining the main thread issue.

--
Peter Dimov
Multi Media Ltd.