Thread safety is when multiple threads access the same object
when multiple threads access the same objects, if not consider alternate scheduling and execution under the environment of these threads at runtime and does not require additional synchronization, or in any caller other actions, calling the object's behavior can get the right result, then the object is thread-safe.
Section 1.1.3 counter example a so-called thread-safe, each object has its own counter mutex, and therefore does not constitute a different object lock contention, lock contention
while performing it does not matter, as long as they are not subject to access the same counter, that is they are different objects have their own lock, but under another condition, if the counter is dynamically created and accessed through a pointer, race condition in front of the object is destroyed when it is there, then that is because the pointer to access the same lock
1.2 Creating an object is simple
object constructor thread safe to do only requirement is not to divulge this pointers during construction
• Do not register any callback in the constructor;
• Do not put this in the constructor pass objects across threads;
• even in the last line of the constructor does not work.
That is in the constructor of the object, then it has not completed this initialization if he is leaked to other objects in another thread it is possible to visit this semi-finished objects, unsafe, undesirable
acceptable practice is to construct and require the use of a callback function, then use a member function is defined it can then call again
class Foo : public Observer
{
public:
Foo();
virtual void update();
// 另外定义一个函数，在构造之后执行回调函数的注册工作
void observe(Observable* s)
{
s->register_(this);
}
};
Foo* pFoo = new Foo;
Observable* s = getSubject();
pFoo->observe(s); // 二段式构造，或者直接写s->register_(pFoo);
1.3 Destruction hard
mutex function can only guarantee one after execution
1.3.2 mutexlock can only be used to read and write data to other members of this class are synchronized, it can not protect the safety of the destructor
This is because, like most long-lived mutexlock members of the object, and the destructor action can be said to occur in after the object is killed, the destruction occurs when the lock has been destructed
Shared_ptr and smart pointers, including two types of unique_ptr
1.4 thread safe observer
same object dangling pointers a pointer to the heap two two pointers are located in different threads, thread A is assumed by a pointer object is destroyed it would watch dangling pointers 2
To secure the best pointer in the case of the destruction of others are secretly do not see (this is the principle of all garbage collection less than what color must be happy ah XD)
good solution: the reference count
1 and 2 the pointer 12 are turned into an object, to an object, the object now point to the middle of the target object has two members, and pointers and counters
when the pointer off its destructor reference number reduction, the number of references becomes 0 know , you can safely destroyed
is not that the reference counting smart pointer it! ! !
1.6 good use! shared_ptr / weak_ptr
shared_ptr control object lifetime
weak_ptr does not control the lifetime of the object, but he knew whether the object is still alive
shared_ptr / weak_ptr is an atomic operation without lock
Mutex read-write locks and
read-write locks: Readers can read more at the same time; writers must be mutually exclusive; in preference to the reader-writer
mutex: Only one thread can have other threads must wait for the mutex
