Re: Degrees of Thread-safety?

From: Markus Schoepflin (schoepflin_at_[hidden])
Date: 2001-09-20 03:27:04

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:

See below...

> The definition of "thread-safe" given in the Boost.Threads docs 
says that a 
> program is thread-safe if it has no race-conditions, deadlocks, or 
priority 
> failures.  A program is either thread-safe or it isn't.  There are 
no 
> degrees of thread-safety.  (I guess you might have a program that 
is 
> thread-safe on a single processor system but not on a multi-
processor 
> system, but hardware isn't what I'm worried about in this message.)
> 
> But when we get to libraries, classes, member functions, and non-
member 
> functions, there seem to be degrees of thread-safety:
> 
>    0)  Not thread-safe.
> 
>    1)  Non-shared objects are thread-safe but only if all access is
>        read-only. (Certain COW string implementations would fit 
here.)
> 
>    2)  Non-shared objects are thread-safe for read/write access.
> 
>         class Foo {
>             int x;
>           public:
>             void set( int v ) { x = v; }
>             int get() const { return v; }
>           };
> 
>        void thread_func() {
>           Foo foo; // foo safe since not shared between threads
>           ...
>           }
> 
>    3)  Shared objects are thread-safe.  (Either stateless or
>        protected by some type multi-threading construct.)
> 
>        int foo;  // foo is shared
> 
>        void thread_func() {
>           ...
>           {
>              multi-threading-exclusion // exact form immaterial
>              foo = ...;
>              ... = foo;
>           }
>         }
> 

I think 3 should actualle by 3a and 3b.

3a) Thread safe for shared/ro.

The SGI STL-Implementation conforms to this level of thread safety. 
See http://www.sgi.com/tech/stl/thread_safety.html

3b) Thread safe for shared/rw.

> While I think the idea of differing degrees of thread-safety is 
correct, my 
> explanation above seems really lame.  Can anyone come up with a 
better 
> explanation?
> 
> What are good names for these degrees of thread-safety?
> 
> Have these degrees of thread-safety already been define well 
elsewhere?
> 
> (We need better definitions since currently different people have a 
> different degree in mind when they use the term "thread-safety".  
The 
> result is much confusion.)
> 
> --Beman

Markus