SGI STL (3) :: Thread Safe

线程安全与锁机制

最新推荐文章于 2021-06-18 11:35:34 发布

原创最新推荐文章于 2021-06-18 11:35:34 发布 · 319 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#sgi

sgi 专栏收录该内容

6 篇文章

订阅专栏

本文探讨了SGI容器的线程安全性问题，包括不同线程同时访问容器时的安全性保障措施，如原子操作和锁定机制的应用，并讨论了现有实现方式的优缺点。

Hi guys

My Email: jakezhang1989@hotmail.com
My GitHub Link

Thank you for taking time to go through this post from which you would get what you want.
If you have any problems or opinions that are different form mins, please email me or leave a comments. I will reply as soon as possible.

OK, Let us get started!

Lock shared mutable containers

SGI is thread-safe only in the sense that
1. simultaneous accesses to distinct containers are safe.
2. simultaneous read accesses to shared containers are safe.
3. If multiple threads access a single container, and at least one thread may potentially write, then the user is responsible for thread safety.
4. wrapping the underlying container operations with a lock acquisition and release. For example, it would be possible to provide a locked_queue container adapter that provided a container with atomic queue operations.
5. For most clients, it would be insufficient to simply make container operations atomic; larger grain atomic actions are needed. If a user’s code needs to increment the third element in a vector of counters, it would be insufficient to guarantee that fetching the third element and storing the third element is atomic; it is also necessary to guarantee that no other updates occur in the middle. Thus it would be useless for vector operations to acquire the lock; the user code must provide for locking in any case.
6. removes all non-constant static data from container implementations. Currently the only explicit locking is performed inside allocators.
7. It would be preferable if we could always use the OS-supplied locking primitives. Unfortunately, these often do not perform well, for very short critical sections such as those used by the allocator (spin_lock is used in allocator)
8. It imposes the restriction that memory deallocated by a thread can only be reallocated by that thread. However, it often obtains significant performance advantages as a result. (because deallocation do not need to be locked in case of ‘who allocates who release‘)