Multithreaded finalization

Other concepts about locks

1, The singleton pattern

The singleton pattern .
scott meyer- Singleton mode and double check

2, Intelligent pointer ,STL

Intelligent pointer

• STL In the container 、 Only pointers are not thread safe .

• as a result of , STL Is designed to maximize performance , When it comes to locking, thread safety is guaranteed , Will have a huge impact on performance . And for different containers , Different locking methods , Performance may also be different ( for example hash Lock table and lock barrel of table ). therefore STL The default is not thread safe . If you need to use it in a multithreaded environment , It is often necessary for the caller to ensure thread safety .

• about unique_ptr, Because it only takes effect within the scope of the current code block , Therefore, thread safety is not involved . about shared_ptr, Multiple objects need to share a reference count variable , So there will be thread safety problems . But this problem is taken into account when implementing the standard library , Based on atomic operation (CAS) In a way that guarantees shared_ptr Can be efficient , Atomic operation reference count .

3, Other locks

• Pessimistic locking , Every time you get data , Always worried that the data will be modified by other threads , Therefore, it will lock the data before getting it （ Read the lock , Write lock , Line lock, etc ）, When other threads want to access data , Blocked and suspended .
• Optimism lock ,： Every time you get data , Always optimistic that the data will not be modified by other threads , So don't lock . But before updating the data , It will judge whether other data has been modified before updating . There are mainly two ways ： Version number mechanism and CAS operation .

The reader writer question

• The problem for readers and writers is that there are many readers , A model with few writers . This kind of chestnut is everywhere in our life ：
• Blackboard newspaper , There are only a few people , But many people read it .
• Based on the different status of readers and writers , Our read-write locks can also be implemented differently .

Reader writer's 321 principle

• Readers share resources with each other ！！ Because the reader doesn't need to change the data .
• Readers and writers are mutually exclusive .（ You can also synchronize ）
• Writers and writers are mutually exclusive .（ You can also synchronize ）

Common interfaces

• init and destroy function , Pass in the read / write lock , Initialization and destruction .

• The reader's lock is different from the writer's lock , So readers have their own way of locking .

• The writer's lock .

• Their unlocking is the same .

Three implementation methods based on read-write lock

• 1, Readers first . That is, try every means to let the reader operate first . If there are readers in critical resources , Writers are not allowed to enter . If the reader and the writer compete for the lock at the same time , Then readers first . The problem with this model is , Write about hunger . Too many readers , The writer waited for a long time without using critical resources .
• 2, Writer first , That is, try every means to let the writer operate first .
• 3, Fair use of locks .
• What we use most often is reader first .

/**********  This is a piece of pseudo code , Used to simulate the implementation of reader first  *********/
pthread_rwlock_t reader, writer; // Apply for two locks 
int reader_nums = 0;  // Used to count the number of readers 

/*****************  Reader's operation  *****************/
Lock(&reader);
reader_nums++;  // To make sure this step is correct , Use reader lock 
if(reader_nums == 1){
     // If there are readers , Then lock the writer 
	Lock(&writer);
}
UnLock(&reader);
// Start reading 
Lock(&reader);
reader_nums--;  // Make sure this step is correct , Use reader lock 
if(reader_nums == 0){
      // There are no readers at this time , Unlock the writer 
	UnLock(&writer);
}
UnLock(&reader);

/*********  The writer's operation  **************/
Lock(&writer);
// Write data 
UnLock(&writer);

• We will find that the reader lock is not to prevent readers from entering , But to prevent the writer from entering . You may ask , So what's the use of reader locks ？ I just lock it for the writer ？
• Reader lock is to ensure that the reader counter is correct .

spinlocks

• Some threads run very short , Some are long . If a long-running thread occupies critical resources , Then we need to suspend the subsequent threads . Suspending also requires destroying resources , Put the thread into the waiting queue and take it out . however , If the thread runs for a short time , We directly ask subsequent threads to continuously apply for critical resources , Don't wait .

• The implementation of our lock may be in the kernel state encapsulated in the user state , So it may cause such a situation ： The kernel is applying for a lock in spin , But the phenomenon that gives us is blocking . Don't be surprised .

Spin lock interface

• The function name only needs to have spin that will do , Just show this one , Not much display .

trylock

• We normally apply for a lock lock, If the application is not successful , Then it will block the waiting .
• and trylock Is not blocking waiting . You can set a time ( It can also be set without ), Time goes by , If the lock application fails , Go straight back .