Re: [boost] thread::join()

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-15 09:24:50

At 08:56 AM 8/15/2001, Alexander Terekhov wrote:
 >
 >> From:  "Scott McCaskill" <scott_at_m...>
 >>
 >> ----- Original Message -----
 >> From: "Beman Dawes" <bdawes_at_a...>
 >> To: <boost_at_[hidden]>; <boost_at_[hidden]>
 >> Sent: Tuesday, August 14, 2001 8:50 PM
 >> Subject: Re: [boost] thread::join()
 >>
 >>
 >> > At 02:51 PM 8/14/2001, Scott McCaskill wrote:
 >> >
 >> >  >Shouldn't thread::join() throw an exception if a thread tries to 
join
 >> >  >itself?  Right now, it will deadlock in such a situation.
 >> >
 >> > It is a documented precondition (Requires), so violation is undefined
 >> > behavior.
 >> >
 >>
 >> Ok, but what is the rationale for this?  Efficiency?
 >
 >yes (with respect to pthread_join()):
 >
 >"The pthread_join() function *may* fail if:
 >
 > [EDEADLK] A deadlock was detected or the value
 >           of thread specifies the calling thread. "
 >
 >"Tradeoff Between Error Checks and Performance Supported
 >
 > Many of the error checks were made optional in order to
 > let implementations trade off performance versus degree
 > of error checking according to the needs of their specific
 > applications and execution environment. As a general rule,
 > errors or conditions caused by the system (such as
 > insufficient memory) always need to be reported, but
 > errors due to an erroneously coded application (such as
 > failing to provide adequate synchronization to prevent a
 > mutex from being deleted while in use) are made optional.
 > A wide range of implementations is thus made possible.
 > For example, an implementation intended for application
 > debugging may implement all of the error checks, but an
 > implementation running a single, provably correct
 > application under very tight performance constraints in
 > an embedded computer might implement minimal checks. An
 > implementation might even be provided in two versions,
 > similar to the options that compilers provide: a full-
 > checking, but slower version; and a limited-checking,
 > but faster version. To forbid this optionality would
 > be a disservice to users.
 >
 > By carefully limiting the use of ''undefined behavior''
 > only to things that an erroneous (badly coded) application
 > might do, and by defining that resource-not-available
 > errors are mandatory, this volume of IEEE Std 1003.1
 > ensures that a fully-conforming application is portable
 > across the full range of implementations, while not
 > forcing all implementations to add overhead to check for
 > numerous things that a correct program never does."
 >                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes.  In terms of the C++ standard, the "erroneously coded application" 
errors are specified as preconditions via a "Requires" clause in the docs, 
and thus error checking is optional.  "Errors or conditions caused by the 
system" are specified in the "Throws" clause in the docs, and thus require 
an implementation to detect and throw on the error condition.

In helping with the Boost.Threads docs, I've been trying to make sure that 
all the "Requires" and "Throws" conditions are specified correctly.  While 
quite a bit of progress has been made, there are still a number of places 
where "Requires" and "Throws" aren't fully specified yet.

One way to do this is to compare asserts and throws in Bill's code to the 
docs, looking for cases not mentioned in the docs.  If someone would like 
to do that, it would be appreciated.

(There is also an open issue that runtime_error is being thrown instead of 
a thread specific error.  runtime_error is just a placeholder waiting for a 
thread specific class.)

--Beman