Linux POSIX多线程编程入门与实践

需积分: 17 32 浏览量更新于2024-07-25 收藏 172KB PDF 举报

在Linux环境下，POSIX多线程编程是一种广泛应用的技术，它允许程序在单个进程中并发执行多个任务，提高系统资源利用率和响应速度。本教程专为初学者设计，涵盖了POSIX线程（pthread）的基础知识和实践操作。 1. **开始之前**：在开始多线程编程之前，理解什么是线程以及为什么要使用线程至关重要。线程是程序执行的独立路径，每个线程可以并行运行，共享同一进程的内存空间。多线程有助于避免阻塞，提高程序的并发性能。 2. **线程概念与使用**：线程可以帮助分解复杂任务，每个线程执行部分工作，同时保持整体进度。在Linux的POSIX环境中，`pthread`库提供了创建、管理和同步线程的功能。 3. **创建和销毁线程**：使用`pthread_create()`函数创建新线程，指定线程函数和必要的参数。线程生命周期管理通过`pthread_join()`和`pthread_exit()`实现，前者等待子线程结束，后者终止线程并返回控制权。 4. **互斥锁（Mutex）**：线程同步的关键机制是互斥锁，它确保在同一时间只有一个线程能访问特定资源。`pthread_mutex_init()`, `pthread_mutex_lock()`, 和 `pthread_mutex_unlock()`用于创建、锁定和解锁互斥锁，防止数据竞争。 5. **死锁与饥饿问题**：学习如何避免或处理线程之间的死锁和饥饿现象，如适当顺序地使用锁和条件变量，以防止一个线程永远无法获取所需的资源。 6. **条件变量（Condition Variables）**：条件变量提供更高级的同步，允许线程在满足特定条件时进入或退出等待状态。`pthread_cond_init()`, `pthread_cond_signal()`, `pthread_cond_wait()`等函数是条件变量的核心操作。 7. **私有线程数据（Thread-Specific Data，TSD）**：线程局部存储，每个线程拥有自己的数据块，确保数据的隔离性。`pthread_key_create()`, `pthread_setspecific()`, 和 `pthread_free()`函数用于管理TSD。 8. **线程取消和终止**：理解如何在必要时取消线程，避免资源泄露。`pthread_cancel()`函数用于请求线程停止执行，而`pthread_detach()`则让系统在子线程结束后自动清理资源。通过本文档提供的实例和步骤，初学者可以逐步掌握POSIX多线程编程的基本原理和实践技巧。学习过程中需要注意线程安全和资源管理，确保程序的稳定性和效率。

Multi-Threaded Programming With POSIX Threads

condition variables, and gets awakened again when the variable is signaled again, and so on. The situation for the un-

awakened thread is called 'starvation'. It is up to the programmer to make sure this situation does not occur if it implies

bad behavior. Yet, in our server example from before, this situation might indicate requests are coming in a very slow

pace, and thus perhaps we have too many threads waiting to service requests. In this case, this situation is actually

good, as it means every request is handled immediately when it arrives.

Note 2: when the mutex is being broadcast (using pthread_cond_broadcast), this does not mean all threads are running

together. Each of them tries to lock the mutex again before returning from their wait function, and thus they'll start

running one by one, each one locking the mutex, doing their work, and freeing the mutex before the next thread gets its

chance to run.

Destroying A Condition Variable

After we are done using a condition variable, we should destroy it, to free any system resources it might be using. This

can be done using the pthread_cond_destroy(). In order for this to work, there should be no threads waiting on

this condition variable. Here is how to use this function, again, assuming 'got_request' is a pre-initialized condition

variable:

int rc = pthread_cond_destroy(&got_request);

if (rc == EBUSY) { /* some thread is still waiting on this condition variable */

/* handle this case here... */

}

What if some thread is still waiting on this variable? depending on the case, it might imply some flaw in the usage of

this variable, or just lack of proper thread cleanup code. It is probably good to alert the programmer, at least during

debug phase of the program, of such a case. It might mean nothing, but it might be significant.

A Real Condition For A Condition Variable

A note should be taken about condition variables - they are usually pointless without some real condition checking

combined with them. To make this clear, lets consider the server example we introduced earlier. Assume that we use

the 'got_request' condition variable to signal that a new request has arrived that needs handling, and is held in some

requests queue. If we had threads waiting on the condition variable when this variable is signaled, we are assured that

one of these threads will awake and handle this request.

However, what if all threads are busy handling previous requests, when a new one arrives? the signaling of the

condition variable will do nothing (since all threads are busy doing other things, NOT waiting on the condition variable

now), and after all threads finish handling their current request, they come back to wait on the variable, which won't

necessarily be signaled again (for example, if no new requests arrive). Thus, there is at least one request pending, while

all handling threads are blocked, waiting for a signal.

In order to overcome this problem, we may set some integer variable to denote the number of pending requests, and

have each thread check the value of this variable before waiting on the variable. If this variable's value is positive, some

request is pending, and the thread should go and handle it, instead of going to sleep. Further more, a thread that handled

a request, should reduce the value of this variable by one, to make the count correct.

Lets see how this affects the waiting code we have seen above.

http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html (10 of 22) [01/04/2003 09:53:00 a.m.]

Multi-Threaded Programming With POSIX Threads

/* number of pending requests, initially none */

int num_requests = 0;

/* first, lock the mutex */

int rc = pthread_mutex_lock(&request_mutex);

if (rc) { /* an error has occurred */

perror("pthread_mutex_lock");

pthread_exit(NULL);

}

/* mutex is now locked - wait on the condition variable */

/* if there are no requests to be handled. */

rc = 0;

if (num_requests == 0)

rc = pthread_cond_wait(&got_request, &request_mutex);

if (num_requests > 0 && rc == 0) { /* we have a request pending */

/* unlock mutex - so other threads would be able to handle */

/* other reqeusts waiting in the queue paralelly. */

rc = pthread_mutex_unlock(&request_mutex);

/* do your stuff... */

/* decrease count of pending requests */

num_requests--;

/* and lock the mutex again - to remain symmetrical,. */

rc = pthread_mutex_lock(&request_mutex);

}

/* finally, unlock the mutex */

pthread_mutex_unlock(&request_mutex);

Using A Condition Variable - A Complete Example

As an example for the actual usage of condition variables, we will show a program that simulates the server we have

described earlier - one thread, the receiver, gets client requests. It inserts the requests to a linked list, and a hoard of

threads, the handlers, are handling these requests. For simplicity, in our simulation, the receiver thread creates requests

and does not read them from real clients.

The program source is available in the file

thread-pool-server.c, and contains many comments. Please read the source

file first, and then read the following clarifying notes.

1. The 'main' function first launches the handler threads, and then performs the chord of the receiver thread, via its

main loop.

2. A single mutex is used both to protect the condition variable, and to protect the linked list of waiting requests.

This simplifies the design. As an exercise, you may think how to divide these roles into two mutexes.

3. The mutex itself MUST be a recursive mutex. In order to see why, look at the code of the 'handle_requests_loop'

function. You will notice that it first locks the mutex, and afterwards calls the 'get_request' function, which locks

the mutex again. If we used a non-recursive mutex, we'd get locked indefinitely in the mutex locking operation

of the 'get_request' function.

You may argue that we could remove the mutex locking in the 'get_request' function, and thus remove the

double-locking problem, but this is a flawed design - in a larger program, we might call the 'get_request'

function from other places in the code, and we'll need to check for proper locking of the mutex in each of them.

4. As a rule, when using recursive mutexes, we should try to make sure that each lock operation is accompanied by

a matching unlock operation in the same function. Otherwise, it will be very hard to make sure that after locking

http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html (11 of 22) [01/04/2003 09:53:00 a.m.]

Multi-Threaded Programming With POSIX Threads

the mutex several times, it is being unlocked the same number of times, and deadlocks would occur.

5. The implicit unlocking and re-locking of the mutex on the call to the pthread_cond_wait() function is

confusing at first. It is best to add a comment regarding this behavior in the code, or else someone that reads this

code might accidentally add a further mutex lock.

6. When a handler thread handles a request - it should free the mutex, to avoid blocking all the other handler

threads. After it finished handling the request, it should lock the mutex again, and check if there are more

requests to handle.

"Private" thread data - Thread-Specific Data

In "normal", single-thread programs, we sometimes find the need to use a global variable. Ok, so good old teach' told

us it is bad practice to have global variables, but they sometimes do come handy. Especially if they are static variables -

meaning, they are recognized only on the scope of a single file.

In multi-threaded programs, we also might find a need for such variables. We should note, however, that the same

variable is accessible from all the threads, so we need to protect access to it using a mutex, which is extra overhead.

Further more, we sometimes need to have a variable that is 'global', but only for a specific thread. Or the same 'global'

variable should have different values in different threads. For example, consider a program that needs to have one

globally accessible linked list in each thread, but note the same list. Further, we want the same code to be executed by

all threads. In this case, the global pointer to the start of the list should be point to a different address in each thread.

In order to have such a pointer, we need a mechanism that enables the same global variable to have a different location

in memory. This is what the thread-specific data mechanism is used for.

Overview Of Thread-Specific Data Support

In the thread-specific data (TSD) mechanism, we have notions of keys and values. Each key has a name, and pointer to

some memory area. Keys with the same name in two separate threads always point to different memory locations - this

is handled by the library functions that allocate memory blocks to be accessed via these keys. We have a function to

create a key (invoked once per key name for the whole process), a function to allocate memory (invoked separately in

each thread), and functions to de-allocate this memory for a specific thread, and a function to destroy the key, again,

process-wide. we also have functions to access the data pointed to by a key, either setting its value, or returning the

value it points to.

Allocating Thread-Specific Data Block

The pthread_key_create() function is used to allocate a new key. This key now becomes valid for all threads in

our process. When a key is created, the value it points to defaults to NULL. Later on each thread may change its copy

of the value as it wishes. Here is how to use this function:

/* rc is used to contain return values of pthread functions */

int rc;

/* define a variable to hold the key, once created. */

pthread_key_t list_key;

/* cleanup_list is a function that can clean up some data */

/* it is specific to our program, not to TSD */

extern void* cleanup_list(void*);

/* create the key, supplying a function that'll be invoked when it's deleted. */

rc = pthread_key_create(&list_key, cleanup_list);

http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html (12 of 22) [01/04/2003 09:53:00 a.m.]

剩余55页未读，继续阅读

xhxzzh1

粉丝: 0
资源: 1

Linux POSIX多线程编程入门与实践

POSIX多线程程序设计（中文）pdf

POSIX标准个人版

POSIX多线程编程指南

posix多线程编程经典

posix多线程编程.chm

Posix多线程编程.pdf

基于posix多线程编程指南

Posix多线程编程—线程属性.doc

POSIX多线程编程基础指南

POSIX多线程编程实战指南

最新资源