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