"joinable"

[David Abrahams-3]

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?

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

David Abrahams-3 wrote:

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?

Is a thread which has finished but hasn't been joined still a "thread of execution"? If not, there is a distinction between joinable and thread of execution. Otherwise attached() seems like a better name.

Johan

[Stefan Seefeld]

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 ?)
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').


Thanks,
       Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Johan Torp <johan.torp@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Stefan Seefeld <seefeld@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

David Abrahams <dave@...> 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.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

Anthony Williams wrote:

> Stefan Seefeld <seefeld@...> 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.

Regards,
       Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Stefan Seefeld <seefeld@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

Anthony Williams wrote:

> Stefan Seefeld <seefeld@...> 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@...> 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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Stefan Seefeld <seefeld@...> writes:

> 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 ?

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Stefan Seefeld <seefeld@...> writes:

> 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.

OK. t.joinable() /really/ means t represents a thread of
execution. 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.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

Stefan Seefeld <seefeld@...> 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.

> I can use all the usual means like mutexes and conditions across
> detached threads, can't I ?

Yes.

> (And even the 'main' thread is one, as you have stated, even though it's
> impossible to obtain a thread object for it.)

Yes. Exactly like a detached thread.

>>  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".)

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

Anthony Williams wrote:

> Stefan Seefeld <seefeld@...> 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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

----- Original Message -----
From: "Anthony Williams" <anthony.ajw@...>
To: <boost@...>
Sent: Wednesday, May 28, 2008 4:35 PM
Subject: Re: [boost] "joinable"

> Stefan Seefeld <seefeld@...> 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.
>
>> I can use all the usual means like mutexes and conditions across
>> detached threads, can't I ?
>
> Yes.
>
>> (And even the 'main' thread is one, as you have stated, even though it's
>> impossible to obtain a thread object for it.)
>
> Yes. Exactly like a detached thread.
>
>>>  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".)
>
> Yes, I did worry about that. Any more ideas?

Hi,

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

Best
Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-4]

"vicente.botet" <vicente.botet@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

Anthony Williams wrote:

> "vicente.botet" <vicente.botet@...> 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 ?

Thanks,

       Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

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.

Johan

[Howard Hinnant]

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

> Anthony Williams wrote:
>> "vicente.botet" <vicente.botet@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost