![]() ![]() In general, use a in any scenario where you are adding and updating keys or values concurrently from multiple threads. The use of the PushRange and TryPopRange may greatly speed up access times. In mixed producer-consumer scenarios, ConcurrentStack is faster for both small and large workloads. When processing time is around 500 FLOPS or more, then both types scale at about the same rate. However, as the number of threads increases, both types slow down because of increased contention, and Stack might perform better than ConcurrentStack. In pure producer-consumer scenarios, when processing time is very small, then and that has an external lock will probably perform about the same with one dedicated pushing thread and one dedicated popping thread. However, when processing time is around 500 FLOPS or more, then the ConcurrentQueue scales better. In mixed producer-consumer scenarios, when the processing time is very small, a Queue that has an external lock scales better than ConcurrentQueue does. Queue does not scale well in this scenario. When processing time is around 500 FLOPS (floating point operations) or more, then the two-thread rule does not apply to ConcurrentQueue, which then has very good scalability. ![]() If you do not enforce this rule, then Queue might even perform slightly faster than ConcurrentQueue on computers that have multiple cores. In this scenario, ConcurrentQueue performs best when one dedicated thread is queuing and one dedicated thread is de-queuing. In pure producer-consumer scenarios, where the processing time for each element is very small (a few instructions), then can offer modest performance benefits over a that has an external lock. An algorithm that scales performs faster on eight cores than it does on two cores. The increase in performance that is proportional to the number of cores on the computer. This document uses the following terms:Īny given thread is either adding or removing elements, but not both.Īny given thread is both adding and removing elements.įaster algorithmic performance relative to another type in the same scenario. If performance is very important, then the best way to determine which collection type to use is to measure performance based on representative computer configurations and loads. ![]() Because performance may vary depending on many factors, the guidance is not specific and is not necessarily valid in all circumstances. The following sections provide general guidance about when to use a thread-safe collection versus its non-thread-safe equivalent that has a user-provided lock around its read and write operations. In other scenarios, the overhead can cause the thread-safe type to perform and scale about the same or even more slowly than the externally-locked, non-thread-safe version of the type. In some scenarios, synchronization overhead is negligible and enables the multi-threaded type to perform significantly faster and scale far better than its non-thread-safe equivalent when protected by an external lock. The amount of overhead depends on the kind of synchronization that is used, the kind of operations that are performed, and other factors such as the number of threads that are trying to concurrently access the collection. Synchronization adds overhead to an operation. To achieve thread-safety, these types use various kinds of efficient locking and lock-free synchronization mechanisms. NET Framework 4 introduced five collection types that are specially designed to support multi-threaded add and remove operations. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |