What is the purpose of thread-safe data structure classes? [closed] - c++

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
AFAIK, a major goal of multi-threaded programming is increasing performance by utilizing multiple processing cores. The point is maximizing parallel execution.
When I see thread-safe generic data structure classes, I feel some irony. Because thread-safety means enforcing serial execution (lock, atomic operation, or whatever), so it's anti-parallel. Thread-safe classes means that serialization is encapsulated and hidden into the class, so we will get more chance to force serial execution - losing performance. It would be better to manage those critical section in larger (or largest) unit - application logic.
So why do people want thread-safe classes? What's the real benefit of them?
P.S.
I meant thread-safe class is a class has only thread-safe methods which is safe to be called from multiple threads simultaneously. Safe means it guarantees correct read/write result. Correct means its result is equal to the result under single-threaded execution. (for example avoiding ABA problem)
So I think the term thread-safety in my question contains serial execution by definition. And that's why I was confused for its purpose and asked this question.

Answer 1

I think you're question has a false assumption: synchronization operations are simply not anti-parallel. There is simply no way to build a parallel mutable data structure without some form of synchronization. Yes heavy usages of those synchronization mechanisms will detract from the ability of the code to run in parallel. But without those mechanisms it wouldn't be possible to write the code in the first place.
The one form of thread safe data structure that doesn't require synchronization are immutable values. However they only work for a subset of scenarios (parallel reads, data passing, etc ...)

Answer 2

Thread safe data structures can be implemented without serialization. It's tricky to get right, but it's doable and is done. Then you have the benefits of concurrency without any bottleneck.

Answer 3

Thread-safe classes means that serialization is encapsulated and hidden into the class, so we will get more chance to force serial execution - losing performance.
Making thread safety the client's responsibility defeats encapsulation (not always). Depending on the context/design, thread safety can be either very complex, or is susceptible to change over time (breaks your program when APIs change), or they are simply not uniform. Abstracting synchronization does not have to equate to a loss; it also has the potential for great benefits -- especially because it is not a subject for novices.
It would be better to manage those critical section in larger (or largest) unit - application logic.
I'm not sure who told you that, but that is not necessarily ideal for all scenarios. Once you get down to implementing concurrent systems, you will realize that choosing the best granularity of synchronization within your designs can make a huge difference in how it operates. Note that the 'best' general design is not always the best for a given usage.
There is not a hard and fast rule here -- Small and shortest (potentially using and acquiring a higher number of locks, however) is better for many designs, whereas largest-unit can increase contention and result in significant blocking. It's really easy to begin an update then spend a lot of time doing things within that update which do not require sustained synchronization of the entire structure during the update. Locking down the whole graph at each access is not always better, and certain components of the structure may be thread safe independent of other components. Therefore, the largest unit approach is frequently likely to enforce serialization which impacts performance, especially as size and complexity grows.
So why do people want thread-safe classes? What's the real benefit of them?
A few good reasons come to mind:
They can be hard to implement correctly, diagnose, and test. High performance concurrent designs are not concepts learned by attending a talk or going through a few online tutorials. It takes a lot of mistakes and time-invested to understand what goes into a good design.
Some structures are very specialized. These may be non-blocking, rely on atomics, or use less typical concurrent patterns or synchronization forms. Example: By default, you may just reach for a mutex when you need a lock, but sometimes a rwlock or spinlock would be better. Sometimes immutability may be better.
Some contexts or domains are very specialized. Designing a single component is often a simple task, but designing an entire system and how components interact is a much larger challenge, and the system may need to operate under special constraints -- relying on that design's synchronization can save you a lot of headache. You may not take the time to benchmark under many different workloads, whereas the person who wrote it has invested the time to understand the implementation and its execution.
It just works. Some people don't want to spend their energy obsessing over concurrency issues. They would rather use a proven, reliable implementation and focus on other aspects of their program. In some cases, people whose software you wind up using may not understand some of these concepts well enough, and you will be grateful when they had chosen to use a proven (or even familiar) design.
Encapsulation. Sometimes encapsulation can result in big performance boosts in concurrent systems. Example: a member or parameter may be conditionally immutable, and that trait may be taken advantage of. In other cases, encapsulation can result in lower acquisitions or reduced blocking. Another case is that encapsulation can reduce the complexity of using the interface -- entire categories of potential threading issues may be removed (although you may be left with a smaller set of constraints).
Less to comprehend. Reuse a well known implementation and understand how it operates, and you have less to learn compared to reviewing an implementation which was hand written (e.g. by your colleague who departed last year).
There are of course downsides, but that is not your question ;)

Answer 4

Often this is why performance-critical multi-threaded code avoids using "thread-safe" containers. Containers like std::vector, etc., are not thread safe. If an application needs shared access to these containers amongst different threads, then the application is responsible for managing that access.
On the other hand, sometimes performance is not the driver for multi-threading. GUI programs benefit from keeping the UI thread separate from the thread that is doing the work. Other threads may be spun off for all sorts of reasons. Generally this can allow a nice separation of responsibilities in the code, and give better overall liveliness to the application. In these cases the goal often isn't high performance per se. Using thread-safe containers may be a perfectly natural choice for these applications.
Of course the best option is to have your cake and eat it too, like some lock-free queue implementations, which allow one thread to feed the queue, another to consume, with no locking (relying only on the atomic nature of certain basic operations).

Answer 5

It all rather depends on what the class is.
Consider a queue. Not every queue needs to be thread-safe. But there is most certainly a need in some cases for a data structure that you can push "stuff" into from one thread, and have the other thread pull "stuff" out of. This improves the parallelism of the threads, because it focuses inter-thread communication into a single location: the inter-thread queue. One side stuffs a sequence of commands in, and the other reads them and executes them when it can. If there are no commands available, it blocks or does whatever.
That demands, on some level, to have a thread-safe class. And since users will likely want to customize it with different kinds of "stuff", a generic implementation provided by the standard library is not unreasonable. Granted, no such thing exists in the C++ standard today, but it's almost certainly coming.
This is not "anti-parallel"; it improves parallelism. Without it, you would have to find some other way for the two threads to communicate. One that will more than likely force one of them to block more often.
Consider a shared_ptr. The cost of making shared_ptr's reference counter thread-safe is trivial next to the very likely possibility of someone screwing it up. It isn't free of course; an atomic increment/decrement isn't free. But it's far from "enforcing serial execution", since any moment of "serial execution" is so short as to be irrelevant in any real program.
So no, these things are not "anti-parallel".