Is there a standard thread safe nomenclature?

tags:

multithreading

views:

answers:

Is there a standard thread safe nomenclature?

Is there a standard terminology that distinguishes between objects that are safe to use in a multi-threaded environment with locking (my object has no unprotected static members) and objects that are safe to use concurrently in a MT environment (maybe because I put locks around all the public methods)?

Let me add a little more explanation: I have a C++ library that is overall safe to use in a multithreaded environment but is not thread safe. The library contains an exception class inherited from std::exception. The what() method returns a char*. Since I'm stuck with the signature defined in the parent, I have to return memory internal to the class rendering this particular method even more unsafe than the rest of the library. I'm looking for some standard terminology to use when documenting this method.

Static methods that can be used in a multi-threaded environment are called "thread safe".

Instance objects that can be used by multiple threads simultaniously are usually called "immutable", since that is the most common mechanism for ensuring thread safety.

If you define "thread safe" in a broad sense to encompass not only the avoidance of data corruption but also the impossibility of a deadlock, then a mutable instance can rarely be made thread safe, since thread safety ultimately depends on how the object is used.

If you define "thread safe" narrowly to mean that the object is always left in a consistant state, then I don't know of any special terminology for such a thing.

It's usually better to define "thread safe" as a property of a whole system rather than an class.

Jeffrey L Whitledge 2010-08-19 15:17:13

Does this mean that you would define the STL containers to be "immutable" but not thread safe?

John Gordon 2010-08-19 15:23:06

Immutability does lead to thread safety, but thread safety can be from other mechanisms than immutability. Therefore, I find this confusing and misleading.

Steven Sudit 2010-08-19 15:27:04

Also, it's not at all hard to make a mutable object thread-safe without deadlocks.

Steven Sudit 2010-08-19 15:27:46

@John Gordon - The STL containers are not immutable, and I would say that they are not at all thread safe.

Jeffrey L Whitledge 2010-08-19 15:30:06

@Steven Sudit - My point is that focusing on protecting the internals of an object rather than how the object is used is not a good approach to creating a multi-threaded program. It often leads to the appearance of safety but not the actual fact. For example, a "thread-safe" container object cannot have a Count property, because such a property would be utterly useless.

Jeffrey L Whitledge 2010-08-19 15:38:41

@Jeff: With all due respect, that's simply not the case. See http://msdn.microsoft.com/en-us/library/dd287234.aspx. The `Count` is necessarily subject to a safe race condition, in that it can only tell you what the count was at the moment you called, not what it will be a moment later. But then again, that's always true.

Steven Sudit 2010-08-19 15:41:38

@Jeff: STL containers are indeed *not* thread-safe. However, they're also not toxic, so nothing stops you from, for example, having a `vector<int>` instance in one thread, and another such instance in a different thread. If they have any statics that they care about, those are properly locked.

Steven Sudit 2010-08-19 15:42:54

@Steven Sudit - OK, I see what you are saying. I hadn't considered the case where two objects of the same class cannot be used in separate threads. I would call such a thing "crazy"!

Jeffrey L Whitledge 2010-08-19 15:49:20

It may be crazy, but it's really easy to do if you're not thinking about it. Almost any class with static data will be unsafe in an MT environment, if you're not thinking about it and don't add a static lock.

John Gordon 2010-08-19 15:58:06

@John Gordon - That is one of several reasons why static data is the evil.

Jeffrey L Whitledge 2010-08-19 15:59:34

"Crazy", "toxic", "evil": they all fit.

Steven Sudit 2010-08-19 17:07:47

ansaurus

tags:

views:

answers:

Is there a standard thread safe nomenclature?

related questions