views:

589

answers:

1

Hi Guys I want to know what is the difference between thread safe Data and Thread Safe Containers

+3  A: 

Thread safe data:

  • Generally refers to data which is protected using mutexes, semaphores or other similar constructs.

  • Data is considered thread safe if measures have been put in place to ensure that:

    • It can be modified from multiple threads in a controlled manner, to ensure the resultant data structure doesn't becoming corrupt, or lead to race conditions in the code.
    • It can be read in a reliable fashion without the data become corrupt during the read process. This is especially important with STL-style containers which use iterators.
  • Mutexes generally work by blocking access to other threads while one thread is modifying shared data. This is also known as a critical section, and RAII is a common design pattern used in conjunction with critical sections.

  • Depending on the CPU type, some primitive data types (e.g. int) and operations (increment) might not need mutex protection (e.g. if they resolve down to an atomic instruction in machine language). However:

    • It is bad practice to make any assumptions about CPU architecture.
    • You should always code defensively to ensure code will remain thread-safe regardless of the target platform.

Thread safe containers:

  • Are containers which have measures in place to ensure that any changes made to them occur in a thread-safe manner.

  • For example, a thread safe container may allow items to be inserted or removed using a specific set of public methods which ensure that any code which uses it is thread-safe.

  • In other words, the container class provides the mutex protection as a service to the caller, and the user doesn't have to roll their own.

LeopardSkinPillBoxHat
@LeopardSkinPillBoxHat: What if there is only one target platform.Is it safe to reduce mutexes where atomic instructions are guaranteed?
the_drow
I don't think you can even guarantee atomic instructions. Who is to say that Intel don't introduce a new CPU in the future that guarantees no atomic instructions? Unlikely, but it's the job of the programmer to ensure that the code remains platform/hardware independent.Having said that, there are benefits to removing unnecessary mutexes if you can guarantee they are definitely not necessary - e.g. faster execution due to less blocking. But you need to understand the threading model intimately to know whether you can safely remove mutex protection.
LeopardSkinPillBoxHat
@Hat: If Intel were to introduce such a processor, then their compiler team would be after the hardware guys with torches and pitchforks. The reason is that C++0x includes atomic versions of integer types (via std::atomic), which for efficiency you would want implemented in hardware wherever possible. For lock-free programming, std::atomic should replace platform-specific assumptions. See Herb Sutter's "Effective Concurrency" articles.
Steve Jessop
@onebyone: As I said, it's unlikely that such a processor would exist, but my point was that a programmer shouldn't rely on the underlying CPU implementation to provide thread safety.
LeopardSkinPillBoxHat
I think it's fine provided you know you're writing platform-specific code, and the "assumptions" are documented properties of the CPU and compiler. And preferably add compile-time checks that blow up if someone blindly tries to port your code. So for instance on x86, int memory access is atomic. Relying on that (with suitable asserts) is no worse than using inline x86 asm. I do agree that code should be written portably by default, but not that it's "bad practice" to ever write non-portable code.
Steve Jessop