Re: [boost] thread::join()

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-15 07:56:50

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

regards,
alexander.