Johan Torp <johan.torp@gmail.com> writes:

Is a thread which has finished but hasn't been joined still a "thread of execution"?

Yes. It's a thread of execution that has finished. It only ceases to exist once it has been joined with or detached: until then, it still consumes OS resources. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Stefan Seefeld <seefeld@sympatico.ca> writes:

David Abrahams wrote:

...

Seems to me that if we have "detach()," it we should be asking whether a thread is "attached()," rather than "joinable()." Our documentation

Agreed.

...

says "if *this refers to a thread of execution..." all over it, which would seem to indicate that joinable() is an important question even when you're not about to join().

I find this phrasing a bit strange. 'thread of execution' sounds like a concept. Is the 'main' thread not a 'thread of execution' ? (And even if no threads are spawned at all ?)

The 'main' thread us a thread of execution, even if no other threads have been spawned. You cannot obtain a boost::thread object that references it though.

If what is referred to is actually an object (as hinted to by the use of '*this', it should be clear by use of an appropriate (type) name ('thread', instead of 'thread of execution').

The *this in question refers to the boost::thread object on which a member function is being called. A boost::thread object may reference a thread of execution (whether running or finished), or it may not reference anything (e.g. a default-constructed boost::thread object). Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Stefan Seefeld <seefeld@sympatico.ca> writes:

I was looking for alternative ways to phrase the "Effects" (in particular to express the "joinable" concept, but ran into some issues:

* There doesn't appear to be any means to query a thread object's state.

A thread is either joinable() or not.

* I can (apparently) invalidate an existing thread object by detaching it.

Yes. Then the object ceases to refer to a thread, and thus joinable() returns false.

* I can construct a thread that doesn't refer to anything (default constructor).

Yes.

Of course there is 'joinable', but that doesn't let me distinguish between a default-constructed ("not-a-")thread, a detached thread, and a thread that has already been joined.

No, it doesn't. From the point of view of the thread object they are all the same: this thread object does not represent a thread, and therefore is not joinable(). In all three cases the thread::get_id() member function will return a default-constructed (not-a-thread) ID. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Anthony Williams wrote:

Stefan Seefeld <seefeld@sympatico.ca> writes:

...

David Abrahams wrote:

...

Seems to me that if we have "detach()," it we should be asking whether a thread is "attached()," rather than "joinable()." Our documentation

Agreed.

...

says "if *this refers to a thread of execution..." all over it, which would seem to indicate that joinable() is an important question even when you're not about to join().

I find this phrasing a bit strange. 'thread of execution' sounds like a concept. Is the 'main' thread not a 'thread of execution' ? (And even if no threads are spawned at all ?)

The 'main' thread us a thread of execution, even if no other threads have been spawned. You cannot obtain a boost::thread object that references it though.

I was looking for alternative ways to phrase the "Effects" (in particular to express the "joinable" concept, but ran into some issues: * There doesn't appear to be any means to query a thread object's state. * I can (apparently) invalidate an existing thread object by detaching it. * I can construct a thread that doesn't refer to anything (default constructor). Of course there is 'joinable', but that doesn't let me distinguish between a default-constructed ("not-a-")thread, a detached thread, and a thread that has already been joined. Anthony Williams wrote:

David Abrahams <dave@boostpro.com> writes:

...

Seems to me that if we have "detach()," it we should be asking whether a thread is "attached()," rather than "joinable()." Our documentation says "if *this refers to a thread of execution..." all over it, which would seem to indicate that joinable() is an important question even when you're not about to join().

Thoughts?

"attached()" seems a good name to me. Just about every member function of boost::thread requires that the thread is joinable() for it to have any meaning.

Now that you have clarified the meaning of 'joinable' (thanks !), I think 'attached' is not a synonym for it. thread t(task); ... t.join(); ... assert(t.attached() == false); // doesn't sound right, does it ? FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Anthony Williams wrote:

...

t.join(); ... assert(t.attached() == false); // doesn't sound right, does it ?

Seems OK to me. t is now "not-a-thread", so attached() should return false.

My point is that this is not a valid question to ask. To me 'not attached' suggests 'detached'. The 'joinable' concept as you describe it covers a larger domain than the 'attached / detached' concept, so the two aren't synonyms. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Anthony Williams wrote:

OK. t.joinable() /really/ means t represents a thread of execution.

Out of curiosity: Why do you consider a detached thread not to be a "thread of execution" ? I can use all the usual means like mutexes and conditions across detached threads, can't I ? (And even the 'main' thread is one, as you have stated, even though it's impossible to obtain a thread object for it.)

However, the implication of the word is "t can be joined", which is too narrow. t.attached() could indeed be read to mean "not detached", which is also not really correct.

t.represents_a_thread() would be strictly correct, but is a bit long-winded.

t.has_thread() is shorter.

I find these really confusing since the word 'thread' appears in two very distinct meanings here. (first as the type of 't', then as "thread of execution".) Stefan -- ...ich hab' noch einen Koffer in Berlin...

Anthony Williams wrote:

Stefan Seefeld <seefeld@sympatico.ca> writes:

...

Anthony Williams wrote:

...

OK. t.joinable() /really/ means t represents a thread of execution.

Out of curiosity: Why do you consider a detached thread not to be a "thread of execution" ?

It is a thread of execution, it's just that no thread object can represent a detached thread.

thread t(task); t.detach(); assert(t.joinable() == false); t is now not joinable any more. But I find it confusing that "t does not refer to a thread of execution", even though I understand that this is not because the thread of execution has ceased to exist, but because t has been reset not to refer to it any longer.

Yes, I did worry about that. Any more ideas?

I still think 'joinable()' is the best name (so far). Stefan -- ...ich hab' noch einen Koffer in Berlin...

"vicente.botet" <vicente.botet@wanadoo.fr> writes:

just a question that could clarify my thoughts, can a non joinable thread be interruptible?

No, because you no longer have a handle with which to interrupt it. I have thought about providing an "interrupt handle" which you can obtain either from a boost::thread object, or by calling boost::this_thread::get_interrupt_handle() or similar, in which case a detached thread would be interruptible. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

On May 28, 2008, at 11:09 AM, Stefan Seefeld wrote:

Anthony Williams wrote:

...

"vicente.botet" <vicente.botet@wanadoo.fr> writes:

...

just a question that could clarify my thoughts, can a non joinable thread be interruptible?

No, because you no longer have a handle with which to interrupt it.

I have thought about providing an "interrupt handle" which you can obtain either from a boost::thread object, or by calling boost::this_thread::get_interrupt_handle() or similar, in which case a detached thread would be interruptible.

But why do you invalidate the thread object after a call to detach ? Why is it impossible to refer to a detached thread ? (And, for that matter, why can't a default-constructed thread not simply refer to the 'main' thread ?)

Why do we have unreferrable (sp?) threads of execution ?

Because when a thread is detached, you can not reliably query it for things such as it's id. You don't know whether the detached thread is still running or not. Perhaps it has terminated, and another thread has been launched and was assigned the same id. If you need to refer to a thread (via a std::thread), just don't detach it. If you want, you can arrange other communication mechanisms with a thread (such as a condition_variable), and then you can detach it and still communicate with it via the cv. -Howard

On May 28, 2008, at 1:25 PM, vicente.botet wrote:

----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, May 28, 2008 5:04 PM Subject: Re: [boost] "joinable"

...

"vicente.botet" <vicente.botet@wanadoo.fr> writes:

...

just a question that could clarify my thoughts, can a non joinable thread be interruptible?

No, because you no longer have a handle with which to interrupt it.

I have thought about providing an "interrupt handle" which you can obtain either from a boost::thread object, or by calling boost::this_thread::get_interrupt_handle() or similar, in which case a detached thread would be interruptible.

Ok, the question now is *should* the joinable and interruptible features of a thead be disociated? IMO they should. We can need to interrupt a thread even if we are no interested when the thread finish.

If should be better if the the implementation is possible, but I don't think that this is a big problem for the user. Most of the applications could work without releasing the resources that are released when a thread is detached, and preserv attached the thread if they want to be able to interrupt it, isn't it?

This sounds like something that should be layered on top of boost::thread, not embedded in it. boost::thread is conceptually a unique-owner situation: A single handle (boost::thread) refers to a single resource (a thread of execution). An owner should be able to do things to that resource without worrying about interference from others. If you're looking at a function with a boost::thread in it, you don't want to have to do a whole program analysis to figure out if the thing might get interrupted out from under you. thread f(thread t) { ... // is it safe to play with t in here? ... return move(t); } I'm not saying you don't need the capability of multiple interruption handles. All I'm saying is this functionality should be put into another type, like shared_future (where one expects - and knowingly pays for - ownership/control to be shared). -Howard

"Peter Dimov" <pdimov@pdimov.com> writes:

Anthony Williams:

...

I have thought about providing an "interrupt handle" which you can obtain either from a boost::thread object, or by calling boost::this_thread::get_interrupt_handle() or similar, in which case a detached thread would be interruptible.

At this point how far would you be from N2178? It does give you this exact functionality, and in addition, one gets always-joinable handles that keep referring to its thread unless assigned something else.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2178.html

Well, the interface is rather different for one thing, N2178 being primarily free functions operating on handles, rather than member functions on a class. Also, I quite like the single-ownership property of boost::thread and std::thread. "Detach" has a definite meaning, in that there is now no thread object referencing a specific thread, and so it can not be joined. If you have copyable handles then you cannot reasonably have detached threads until all the handles have gone away, and even then if you can get one back with self(), you cannot really have detached threads. Then again, do we need detached threads? With single-ownership (and no interruption_handles), as Howard says, you know whether or not a thread can be interrupted. I'm not sure whether or not this is important. I can see use cases for this_thread::get_interruption_handle(), since it would allow a thread to store it in a shared location for another thread to interrupt it. However, you can probably achieve the same thing by providing a function in that shared data that has access to the boost::thread object in question. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

"Peter Dimov" <pdimov@pdimov.com> writes:

The "interrupt handle" is very similar to thread::handle. The allowed operations on a thread::handle are cancel/interrupt and join/wait; and if you follow through with the "interrupt handle" idea you'll eventually see that many of the use cases in which you need an "interrupt handle" also require a "wait handle" as well. Once you add the ability to wait on an "interrupt handle", there are no differences left.

Possibly.

...

Also, I quite like the single-ownership property of boost::thread and std::thread.

"Ownership" doesn't quite apply to a thread, in the usual resource-management sense of the word, in which the thread basically owns itself.

In the "thread manager" sense, allowing observers to wait for a thread to end does not compromise your ownership of that thread. Giving foreigners the ability to interrupt one of your threads can, if you consider control over when a thread terminates part of your ownership.

Yes, and this is the bit that makes me wary about providing interrupt handles.

In this latter case, either you execute foreign code in your thread, or not. If you don't, nobody can obtain a handle to your thread, and your ownership is still absolute. If you do, things get more hairy, since you usually want to give the client who submits the task the ability to cancel it. We don't have a good solution to this problem yet, in any of our proposals (an "interrupt handle" with an expiration date.)

In order to cancel just a task we need to have an handle that can be used to cancel just that task, whatever thread it happens to be running on, without affecting other tasks running on that thread. Just thinking this through suggests to me that we could use the ability to install a new interrupt handle from within a thread. We could provide something like: template<typename Callable> bool call_interruptibly(interruption_handle h,Callable f); In which interruption on the handle h (and ONLY on the handle h) will trigger an interruption at the usual interruption points. If the call is interrupted, then this function returns false, otherwise it returns true. All non-interrupt exceptions are propagated normally. This would enable a thread to pass out an interruption handle that only applied to a specific bit of code. This could be used in e.g. packaged_task to allow the task to be interrupted without affecting any other tasks that are running on that thread. get_interruption_handle() would not be provided. Thoughts? Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

On May 28, 2008, at 12:05 PM, Johan Torp wrote:

Anthony Williams-4 wrote:

...

...

...

t.has_thread() is shorter.

I find these really confusing since the word 'thread' appears in two very distinct meanings here. (first as the type of 't', then as "thread of execution".)

Yes, I did worry about that. Any more ideas?

represents_execution, has_handle, has_os_handle, is_empty. I think attached/is_attached is better though.

I agree with Stephan that !attached() implies that the thread was detached(), which is inaccurate. -Howard

On May 28, 2008, at 3:49 PM, Johan Torp wrote:

Howard Hinnant wrote:

...

I agree with Stephan that !attached() implies that the thread was detached(), which is inaccurate.

You could update the boost documentation and c++ standard to state "attached to a thread of execution" instead of "represents a thread of execution". Then a default constructed thread would not be attached to a thread of execution and only those attached can be joined.

<shrug> We could call it foobar() and document it too. The point of the "best" name is to make it most likely for someone to understand what it does without reading (or re-reading) the docs. -Howard

on Wed May 28 2008, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:

David Abrahams <dave@boostpro.com> writes:

...

Seems to me that if we have "detach()," it we should be asking whether a thread is "attached()," rather than "joinable()." Our documentation says "if *this refers to a thread of execution..." all over it, which would seem to indicate that joinable() is an important question even when you're not about to join().

Thoughts?

"attached()" seems a good name to me. Just about every member function of boost::thread requires that the thread is joinable() for it to have any meaning.

I've used the same wording for boost::thread::id as well, but clearly an ID is not joinable(). OTOH, a thread::id could be attached(), meaning it actually represents a thread rather than "not-a-thread".

Are you going to be at Sophia-Antipolis? It might be worth raising the same issue wrt std::thread.

I won't be there this time :( -- Dave Abrahams BoostPro Computing http://www.boostpro.com