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?
> "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."
> 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."
> "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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk