Re: [boost] "Thread-safe", etc. definitions [was: Re: Threads Review]

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-19 08:19:10

Alexander Terekhov <terekhov_at_[hidden]> writes:

> David Abrahams wrote:
> [...]
> > * "Thread-safe": this is a term which is well-defined for programs. It
> >   is /not/ well-defined for classes or functions, though the
> >   documentation uses it that way repeatedly. ....

What I wrote above applies if you accept /our/ definition of
"thread-safe".  The definitions below are good ones. Why aren't we
using these, instead of the ones we have?

> http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html#tag_03_313
> 
> "Reentrant Function
> 
>  A function whose effect, when called by two or more threads, 
>  is guaranteed to be as if the threads each executed the function 
>  one after another in an undefined order, even if the actual 
>  execution is interleaved."
> 
> http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html#tag_03_396
> 
> "Thread-Safe
> 
>  A function that may be safely invoked concurrently by multiple 
>  threads. Each function defined in the System Interfaces volume 
>  of IEEE Std 1003.1-2001 is thread-safe unless explicitly stated 
>  otherwise. Examples are any "pure" function, a function which 
>  holds a mutex locked while it is accessing static storage, or 
>  objects shared among threads."
> 
> http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html#tag_03_23
> 
> "Async-Cancel-Safe Function
> 
>  A function that may be safely invoked by an application while 
>  the asynchronous form of cancelation is enabled. No function 
>  is async-cancel-safe unless explicitly described as such."

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html