Boost logo

Boost :

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

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.)


Boost list run by bdawes at, gregod at, cpdaniel at, john at