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