pthread mutex unlock why same thread?

May be a basic ques开发者_如何转开发tion?.

1) Why the mutex should be unlocked on the same thread ?. Do we have any specific reason? 2) Why to keep pthraed_mutex_lock when the same be achieved by sem_wait/sem_post if i understand correctly ?

A mutex is designed to be extremely fast and lightweight in the most common case. The most common case is when a thread enters a critical section, does a few quick changes to shared state, and then exits the critical section. If you have more complex requirements, use a more complex synchronization object. But typically, a pthread mutex will be lighter than almost any other synchronization primitive.

While they can sometimes be used interchangeably, mutexes and semaphores have very different conceptual foundations. The degree to which their actual behavior differs depends on your particular application.

A mutex conceptually has an owner - one thread which, by convention/contract, the programmer treats as the only thread allowed to access the resource(s) which the mutex protects. Depending on the type of mutex it is and the implementation, the owner may be purely a formal construct, or may be an actual field stored in the mutex object. For recursive or error-checking mutexes, for example, storing an owner allows the thread that owns the mutex to obtain additional reference counts on it, or to obtain an error if it tries to re-lock it while the lock is still held, respectively.

A semaphore, on the other hand, is fundamentally a counter. Waiting on a semaphore is not necessarily tied to obtaining exclusive rights to using a resource, although of course that's one potential application (a semaphore which only takes on the values 0 and 1 can be used as a mutex). Semaphores can be used for many other applications, like waiting/signaling - for example, one thread could loop waiting on a semaphore N times to wait for N threads to post to it, where each thread posts when it finishes a task. In fact, a synchronization object equivalent to condition variables can also be implemented in terms of semaphores. They can also be used simply as a portable atomic counter (posting to increment the counter), among many other uses. The "classic" use of a semaphore is to represent the number of available resources from among N equivalent resources, and facilitate waiting when no resources are available, but personally I don't think I've ever used semaphores quite like that.

Now if you want to get into the specifics of POSIX mutexes and semaphores, for the most part semaphores are much more powerful. Not only can they be used for signalling conditions; the post operation is also async-signal-safe meaning you can use it without restriction from inside signal handlers. On the other hand, mutexes do have one feature which cannot be implemented in terms of semaphores: the robust mutex attribute, which allows you to create mutexes that allow other threads/processes to detect and recover when a thread/process terminated while holding the mutex (rather than just deadlocking).

Because that's what a mutual exclusion semaphore is for, mutual exclusion (excluding all other threads except this one).

It's to lock a resource so that a particular thread of execution has unfettered access to it.

"Regular" semaphores (as in sem_wait/sem_post) are counted semaphores. You can specify that there are N resources available rather than just one as per mutual exclusion. You can certainly emulate mutual exclusion semaphores with the regular variety but you lose some of the protections (such as ensuring only the owner can unlock it).