Degrees of Thread-safety?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-09-19 15:34:26

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;
          }
        }

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