So Linux backend programming (3) : Threads and stuff

In architectures with shared memory for multiple processors (e.g., symmetric multiprocessing system SMP), threads can be used to achieve program parallelism. Hardware vendors have historically implemented proprietary versions of multithreaded libraries, forcing software developers to be concerned about portability. For UNIX systems, the IEEE POSIX 1003.1 standard defines a C multithreaded programming interface. Implementations that are attached to the standard are called POSIX TheADS or Pthreads.

This tutorial introduces the concept, motivation, and design of Pthreads. It covers the three main categories of Pthreads API functions: Thread Managment, Mutex Variables, and Condition Variables. Examples are provided to programmers who are just beginning to learn Pthreads.

Suitable for: beginning to learn parallel programming using threads; Basic knowledge of C parallel programming.

Officially, it is the smallest unit in which an operating system can schedule operations. It is contained within the process and is the actual operating unit within the process. A thread is a single sequential flow of control in a process, and multiple threads can be concurrent in a process, each performing a different task in parallel.

1, improve the concurrency of the program2, low overhead, no need to reallocate memory3, easy to communicate and share dataCopy the code

(1) Thread is also called lightweight process, also has PCB, thread creation using the same low-level function and process, are clone. (2Threads and processes look the same from the kernel, each with a different PCB, but the PCB points to a different three-level page table of memory resources. (3A process can be morphed into a thread, or a main thread, which is the main road of a highway. (4Under Linux, a thread is the smallest unit of execution and a process is the smallest unit of allocated resources.Copy the code

1Thread instability (this is really unstable, there will be an article on the effects of reentrant functions on threads, because I haven't sorted that out yet)2Thread debugging is difficult (this is a real headache, difficult to debug things, so far I only have a "segment error, core has been dumped" can be used, the key is that the error is difficult to reproduce, difficult, difficult)3Threads cannot use classic Unix events such as signals.Copy the code

For example, suppose your program creates several threads, each calling the same library function:

This library function accesses/modifies a global structure or location in memory. When each thread calls this function, the global structure live memory location may be modified at the same time. If the function does not use synchronization to prevent data corruption, then it is not thread-safe.

If you are not 100% sure that external library functions are thread-safe, you are responsible for any problems that may arise. Suggestion: Be careful when using libraries or objects that are not explicitly thread-safe. If in doubt, assume it is not thread-safe until proven. You can find the problem by constantly using the indeterminate function.Copy the code

Take a look at this article (to be rewritten in a few days) : What reentrant functions mean for thread-safety

#include<pthread.h>

int pthread_create(pthread_t *thread,const pthread_tattr_t *attr,void *(*start_routine)(void *),void *arg);

/* Thread: this is an outgoing argument that passes a pthread_t variable, which is used to store the tid of the new thread. Attr: this is a thread property setting. NULL indicates that the default value is used. Function pointer to a new thread should point to arg function modules: old ripe, to the preceding function and use of, don't preach and then write a NULL return value: returns 0. Success, failure return error, error number and error number, said earlier errno is not Shared. Note (1) : There are no special cases in which we use the default properties when creating a thread, but sometimes we need to do something special, such as adjust the priority. * /
Copy the code

Q: How do YOU safely pass data to a newly created thread? A: Ensure that the data being passed is thread-safe (cannot be modified by other threads). Here are three examples of what should and shouldn’t be.

Code demo:

// Example Code - Pthread Creation and Termination  

#include <pthread.h> 
#include <stdio.h> 
#define NUM_THREADS     5 

void *PrintHello(void *thread_id) 
{ 
   int tid; 
   tid = (int)thread_id; 
   printf("Hello World! It's me, thread #%d! \n", tid); 
   pthread_exit(NULL); 
} 

int main(int argc, char *argv[]) 
{ 
   pthread_t threads[NUM_THREADS]; 
   int rc, t; 

   for(t=0; t<NUM_THREADS; t++){ 
      printf("In main: creating thread %d\n", t); 

      rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t); 

      if (rc){ 
         printf("ERROR; return code from pthread_create() is %d\n", rc); 
         exit(- 1); }}pthread_exit(NULL); 
} 
Copy the code

Next to demonstrate thread safety:

// The following snippet demonstrates how to pass a simple integer to a thread.
// The main thread uses a unique data structure for each thread to ensure that the parameters passed by each thread are complete.
int *taskids[NUM_THREADS]; 

for(t=0; t<NUM_THREADS; t++) 
{ 
   taskids[t] = (int *) malloc(sizeof(int)); 
   *taskids[t] = t; 
   printf("Creating thread %d\n", t); 
   rc = pthread_create(&threads[t], NULL, PrintHello,(void*) taskids[t]); . }Copy the code

// This example shows how to set/pass parameters to a thread using a structure. Each thread gets a unique instance of a structure.

struct thread_data{ 
   int  thread_id; 
   int  sum; 
   char *message; 
}; 

struct thread_data thread_data_array[NUM_THREADS]; 

void *PrintHello(void *threadarg) 
{ 
   struct thread_data *my_data;. my_data = (struct thread_data *)threadarg; taskid = my_data->thread_id; sum = my_data->sum; hello_msg = my_data->message; . }int main (int argc, char *argv[]) 
{... thread_data_array[t].thread_id = t; thread_data_array[t].sum = sum; thread_data_array[t].message = messages[t]; rc =pthread_create(&threads[t], NULL, PrintHello,(void*) &thread_data_array[t]); . }Copy the code

// This example demonstrates passing parameters incorrectly. The loop changes the contents of the address passed to the thread before it accesses the passed parameters.

int rc, t; 
for(t=0; t<NUM_THREADS; t++)  
{ 
   printf("Creating thread %d\n", t); 
   rc = pthread_create(&threads[t], NULL, PrintHello,(void*) &t); . }Copy the code

#include<pthread.h>

int pthread_self(pthread_t t1,pthread_t t2);
Copy the code

Note that the thread ID objects in both functions are opaque and not easily examined. Because thread ids are opaque objects, the C == operator cannot be used to compare two thread ids.

In Linux, thread attributes can be set based on actual project needs. Previously, we discussed the default properties of threads, which already solve most of the requirements of thread development. If you want higher performance, you need to manually configure the thread properties.

 typedef struct
{
    int detachstate; // Separate state of the thread
    int schedpolicy; // Thread scheduling policy
    struct　sched schedparam;// Scheduling parameters for the thread
    int inheritsched; // Thread inheritance
    int scope; // Scope of the thread
    size_t guardsize; // Alert buffer size at the end of the thread stack
    int stackaddr_set; // Set the thread stack
    void* stackaddr; // Start position of thread stack
    size_t stacksize; // Thread stack size
}pthread_attr_t;

// We can see the related parameters in this structure above
Copy the code

The default properties are unbound, undetached, default stack, and the same level of priority as the parent process.

General routines for setting thread properties:

First: Define and initialize attribute variablespthread_attr_t
                            pthread_attr_init(a)Second: call the interface function for the property you want to setpthread_attr_setxxxxxxxx(a)Third: use this property for the second argument when creating the thread. Fourth: Destroy the propertypthread_destroy(a);
Copy the code

Let’s do a little experiment. Two thread counts. If it adds up to 200,000 you don’t have to look down.

#include<pthread.h>
#include<unistd.h>
#include<stdio.h>

int count = 0;// Declare a global variable, we'll see it later

void *run(void *arg)
{
	int i = 0;
	for(i = 0; i <100000; i++)
	{
		count++;
		printf("Count:%d\n",count);
		usleep(2);
	}
	return (void*)0;
}

int main(int argc,char **argv)
{
	pthread_t tid1,tid2;
	int err1,err2;

	err1 = pthread_create(&tid1,NULL,run,NULL);
	err2 = pthread_create(&tid2,NULL,run,NULL);

	if(err1==0 && err2==0)// Both threads were created successfully
	{
		pthread_join(tid1,NULL);
		pthread_join(tid2,NULL);
	}
	return 0;
}
Copy the code

Okay, so why synchronize the threads

Forget it. We’re gonna have to make it official

(1) Multiple threads can operate on shared resources. (2) Threads may not operate on shared resources in the order in which they operate. (3) Processors generally do not operate on memory atomically

< here only define that init>

Parameter 1: an outgoing parameter that should be passed &mutex RESTRICT keyword: this is only used to restrict the pointer. It tells the compiler that all operations that change the pointer to the contents of the memory can be performed only by this pointer. Cannot be modified by a variable or pointer other than this pointer.

Parameter 2: mutually exclusive property. Is an passed argument, usually NULL, using the default property (shared between threads). Static initialization: If the mutex is statically allocated (defined globally, or modified with the static keyword), it can be initialized directly using macros. pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; Dynamic initialization: Local variables should be dynamically initialized. pthread_mutex_init(&mutex, NULL);

The attr object is used to set the attributes of the mutex object. It must be declared as pthread_mutextattr_t. The default value can be NULL. The Pthreads standard defines three optional mutex attributes: Protocol: specifies the Protocol used to prevent the mutex priority from changing. Prioceiling: Specifies the mutex priority upper limit. Process-shared: specifies the Process to share the mutex

Note that all implementations provide these three optional mutex attributes.

Q: There are multiple threads waiting for the same locked mutex. When the mutex is unlocked, which thread is the first to lock the mutex? A: Unless the thread uses A priority scheduling mechanism, the thread will be allocated by the system scheduler, and that thread will be the first to lock the mutex is random.Copy the code

(The last progress · Family Bucket devoted a lot of space to this issue.)

Why I want to emphasize that lock and unlock must be written together, is to prevent human error resulting in deadlock deadlock, can not be unlocked. Either you forget to unlock it, and no one else can use it, or several threads are choking on key data so that no one can complete the task, and no one can unlock it. In this case, only destroy the cheapest lock and let the mission continue, but remember to restart the destroyed mission later.

Optimistic locks, as you can see from their name, keep things simple. They assume that resources and data will not be changed, so they will not be locked, but optimistic locks will determine whether the current data has been changed when writing. Mechanisms such as version numbers can be used.

Optimistic locking is suitable for multiple application types to improve throughput.

Use self-growing integers to represent the data version number:



If the two characters do not interfere with each other, the male takes out and the version number is 0, the male writes and the version number is +1; If she writes, version number 1, if she writes, version number 2.

If they interfere with each other, the man picks out version 0; The male hasn’t written it yet, the female has taken it out, version number is 0; Male write, version number 1; If the version number does not match, the write fails and the amount and version number should be read again.

Alternatively, this can be done by timestamp

Let’s just say, each to his own.

Optimistic locking works when there are few writes, i.e. conflicts are really rare, which can eliminate the overhead of locking and increase the overall throughput of the system. However, if there is a lot of conflict, this can actually degrade performance, so pessimistic locking is appropriate in this case.

Pessimistic locking can lead to long database access times and poor concurrency, especially for long transactions. Optimistic locking is often used in reality.

• Condition variables provide another way to synchronize. Muexes enable synchronization by controlling access to data, while condition variables allow synchronization based on actual data values.
• Without the condition variable, the programmer must use threads to poll (perhaps in critical sections) to see if the condition is met. This is more resource-intensive because the threads are busy working continuously. Condition variables are one way to implement this polling.
• Conditional variables are often used with mutexes

The representative order for using conditional variables is as follows:

In a common thread pool used in server programming, multiple threads operate on the same task queue. Once a new task is found in the task queue, the child thread will fetch the task. Here, because it is multithreaded, it must involve protecting the task queue with a mutex (otherwise one of the threads manipulates the task queue, and in the middle of fetching the thread, the thread switches and retrieves the same task). But an obvious disadvantage of a mutex is that it has only two states: locked and unlocked. Imagine each thread constantly having to lock the task queue, check if there are new tasks in the task queue, acquire new tasks (with new tasks) or do nothing (with no new tasks), and release the lock in order to acquire new tasks. This would be very resource-intensive.

Condition variables complement mutex by allowing a thread to block and wait for another thread to send a signal. They are often used in conjunction with mutex. When used, condition variables are used to block a thread, and when the condition is not met, the thread tends to unlock the corresponding mutex and wait for the condition to change. If one of the other threads changes the condition variable, it tells the corresponding condition variable to wake up one or more threads that are blocked by the condition variable. These threads will re-lock the mutex and retest whether the condition is met. In general, condition variables are used for synchronization between threads. Corresponding to the thread pool scenario, we can have threads in a wait state, notify (one or more) when the main thread puts a new task on the work queue, and the notified thread reobtains the lock, acquires the task, and performs the related operation.

Either mode of waiting must be paired with a mutex to prevent multiple threads from disturbing it. The mutex must be normal or adaptive and must be locked by the local thread before entering pthread_cond_wait. Mutex must remain locked until the wait queue is updated. Unlock the thread before it enters the hang and waits. Lock the pthread_cond_wait until the condition is satisfied and the pthread_cond_wait is left. To restore its state before entering cont_wait.

Why is waiting locked?

To avoid wake loss problems. Here's a great explanation for whether to watch: HTTPS://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutexDo the whole thing, source code also put here: HTTPS://code.woboq.org/userspace/glibc/nptl/pthread_cond_wait.c.html
Copy the code

Add thread to wake queue to unlock thread. Ensures that a thread is atomic between the time it is in wait and the time it is added to the wake queue. But this atomicity depends on one prerequisite: the wake-er must also lock the same MUtex before calling the pthread_cond_broadcast or pthread_cond_signal to wake up the wait. If the above conditions are met, if A wait event A occurs before the wake event B, then A also obtains mutex before B, then B cannot enter the wake call before A is added to the wake queue, so B must be able to wake up A. For example, if there is no MUtex to synchronize between A and B, although B occurs after A, A may not be added to the wake queue when B wakes up, which is called wake loss.

Calling the pthread_cond_signal or pthread_cond_broadcast functions when the thread has not acquired the corresponding mutex can cause wake loss problems. Wake loss usually occurs when a thread calls the pthread_cond_signal or pthread_cond_broadcast function; Another thread is between testing the condition variable and calling the pthread_cond_wait function; No thread is in a blocking wait state.Copy the code

The thread pool

Object destruction, in multithreading, is complicated by the existence of races. Here’s an example:

Foo::~Foo() {/ / lock
	/ / destructor
	/ / unlock
}
void Foo::update(a){
	/ / lock
	// Data manipulation
	/ / unlock
}

extern Foo *f;// Share resourcesA Process Operationsdelete f;
f = NULL; B Process Operationsif(f)
{
	f->update(a); }Copy the code

This would be an awkward situation: WHEN A does the destructor, it already has the lock, but B passes F’s judgment because the pointer is still alive at that point and then gets stuck in the lock. What happens next? I don’t know, because the object takes the lock with it when it destructs… (The lock belongs to the object, object destructor, lock can not escape)

So what? Don’t worry, check out the blog: Smart Pointers

You can’t tell if a dynamically created object is still valid by looking at a pointer. A pointer is just pointing to a block of memory that, if it’s been destroyed, can’t be accessed.

The possible memory problems in C++ have several general aspects

• Buffer overflow
• Null dangling pointer/wild pointer
• Repeated release
• A memory leak
• Unpaired new[]/delete
• Memory fragments

Corresponding solutions:

• std::vetor
• shared_ptr/weak_ptr
• Scoped_ptr, only released once during object destruction
• scoped_ptr
• std::vetor