Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-27 14:06:02

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> Bill Kempf wrote:
> >4) Will the usage of this design make users opt for the native C
> >APIs instead of the Boost.Threads library.
> If you are worried (and I think it is a reasonable worry until we
> experience to tell us otherwise), then also provide the thread_id
> thread_desc, thread_handle, or whatever you prefer to call it)
> oriented interface.

Duplicate interfaces for the same concept?
> I know that is asking you to do more work, but neither of these
> huge. I'll volunteer to do the docs.

The extra work doesn't bother, it's the duplication of effort that
does. It seems like your asking us to develop two parallel designs
and let the users vote for the best, just to deprecate one later.
> If later we decide to deprecate one or the other, it would be on
the basis
> of hard experience and not just speculation.

You'll not want both, so one or the other will be deprecated. This
will break any code that (foolishly) chose the "loser".

> >5) Are the join(), detach() and destructor semantics
> >and usable?
> They seem OK to me, but what do developers with lots of threading
> experience say?
> > For example, what happens if you call a method on a
> >thread object that's been detached? I would expect an error.
> I would expect an error usually too. What are the semantics of
> is_alive()? Would is_current() also be an error?

I would expect them to be errors (exceptions thrown?). The thread
object is no longer referencing a thread (even if the original thread
is still running) making calls to is_alive() and is_current()
> > If
> >that's the case should join() detach the thread, or simply wait
> >the thread to finish, being a noop if the thread is already
> >finished? wait for finish. detach() right away would be very
> counterintuitive to me, (but I only have very light thread
> > Should the destructor detach() the thread or join() it?
> Prior examples seemed to show detach() as preferable. You
> join() if you want to wait, otherwise just destroy the object.
Although I
> don't know if it is a big issue; if ~thread() has join() semantics,
> could always explicitly detach() first. Which would be a more
> mistake; to forget to do a join() and have the dtor detach(), or
forget to
> do a detach() and have the dtor join()?

Very good question, and it completely depends on what you expected to
happen. Forget to join and you get race conditions. Forget to
detach and you might deadlock. Both are serious possibilities.

> Thanks for keeping going through such protracted discussions!

Hey, it's important discussion, and I'm glad the thread concept is
finally getting it ;).

Let me summarize the two main interfaces that people seem to think
are the best, and try and flesh them out completely, adding more
questions as I go.

Interface 1:

class thread : boost::noncopyable
        thread(detail::threadproc proc);

        bool is_current() const;
        bool is_alive() const;

        void join() const;
        void detach();

void sleep(const xtime& xt);
void yield();

The constructor creates a thread from any function object (includes
function pointer) that takes no arguments.

The destructor shall either join() or detach(). See the comments

The is_current() method returns true if the calling thread is the
same as the thread object. It's an error to call this method on a
detached thread object.

The is_alive() method returns true if the thread is still running.
It's an error to call this method on a detached thread object. In
general this method should not be used with a preference for join().
However, some busy wait situations can make use of this effectively.

The join() method waits for the thread to finish but the thread
object remains "attached". It's an error to call this method on a
detached thread.

The detach() method puts the thread object in a detached state in
which there is no longer a relationship between the object and the
running thread. This will allow the thread to simply "evaporate"
either when it finishes or the main thread is terminated.


1. I still worry about the lack of self().

2. We need to figure out which is better, to detach() or join() in
the destructor. Conceptually detach() seems like the best
alternative, but this may complicate some user code where join()
needs to be called. Otherwise it seems to be a coin flip and we just
need to pick one and stick with it.

Interface 2:

namespace thread
   class ref
      ref(const ref& other);

      ref& swap(const ref& other);
      ref& operator=(const ref& other);

      bool operator==(const ref& other) const;
      bool operator!=(const ref& other) const;

      bool is_current() const;
      bool is_alive() const;

      void join();

   ref create(detail::threadproc proc);
   void sleep(const xtime& xt);
   void yield();

The actual thread state is an internal detail managed through a ref-
count which is "owned" by both ref objects and the executing thread.
So this state is deleted when BOTH the thread has finished AND there
are no more ref instances referring to the state. Because of this
there's no need for a detach() method.

The ref default constructor constructs a ref that doesn't refer to
any thread.

The ref copy constructor increments the ref-count on the thread state

The ref destructor decrements the ref-count on the thread state.

The ref swap() method allows for fast swapping of ref objects and is
used for exception safe assignment.

The ref assignment operator uses swap() and the copy constructor to
insure exception safe assignment and proper ref-count manipulation.

The ref comparison operators can be used to compare ref objects to
see if they refer to the same thread.

The ref is_current() may eliminate the need for a self() method and
is used to see if the calling thread is the same as the thread
referred to by the ref object. See comments below.

The ref is_alive() method returns true if the referred to thread is
still running. In general this method should not be used with a
preference for join(). However, some busy wait situations can make
use of this effectively.

The ref join() method waits for the referred to thread to complete.

The create() method starts a new thread of execution and creates the
thread state needed, returning a ref object that refers to this.


1. As with the first design I still think that self() may be
needed. However, self() is an easy method to add to this design,
while it's impossible to add to the previous one.

2. The ref-counting will make some operations slower (especially
since the ref-counting must be thread safe).

Other thoughts or comments on the two?

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at