SGI STL (3) :: Thread Safe

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

github_31737299

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

阅读量272

点赞数

分类专栏： sgi 文章标签： sgi

本文链接：https://blog.csdn.net/github_31737299/article/details/50825514

版权

sgi 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

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‘)