pthread互斥解锁为什么同一线程？
可能是一个基本问题？
1）为什么互斥锁应该在同一线程上解锁？我们有什么具体的理由吗？ 2）如果我理解正确的话，为什么要保留 pthraed_mutex_lock 当通过 sem_wait/sem_post 实现相同的功能时？
May be a basic question?.
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
互斥锁被设计为在最常见的情况下非常快速且轻量级。最常见的情况是线程进入临界区，对共享状态进行一些快速更改，然后退出临界区。如果您有更复杂的需求，请使用更复杂的同步对象。但通常情况下，pthread 互斥体比几乎任何其他同步原语都要轻。
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.
虽然互斥体和信号量有时可以互换使用，但它们具有非常不同的概念基础。它们的实际行为的不同程度取决于您的特定应用程序。
互斥锁在概念上有一个所有者 - 一个线程，根据约定/约定，程序员将其视为唯一允许访问互斥锁保护的资源的线程。根据互斥体的类型和实现，所有者可能纯粹是一个形式构造，也可能是存储在互斥体对象中的实际字段。例如，对于递归或错误检查互斥体，存储所有者允许拥有该互斥体的线程获得其上的附加引用计数，或者如果在仍持有锁时尝试重新锁定互斥体，则分别获得错误。
另一方面，信号量本质上是一个计数器。等待信号量并不一定与获得使用资源的独占权相关，尽管这当然是一种潜在的应用（仅采用值 0 和 1 的信号量可以用作互斥锁）。信号量可用于许多其他应用程序，例如等待/信号发送 - 例如，一个线程可以循环等待信号量
N次，以等待N线程向其发送消息，每个线程在完成任务时发布信息。事实上，相当于条件变量的同步对象也可以通过信号量来实现。除许多其他用途外，它们还可以简单地用作便携式原子计数器（发布以增加计数器）。信号量的“经典”用法是表示 N 个等效资源中可用资源的数量，并在没有可用资源时方便等待，但我个人认为我从未使用过信号量就像这样。现在，如果您想了解 POSIX 互斥体和信号量的细节，大多数情况下信号量要强大得多。它们不仅可以用于信号条件； post 操作也是异步信号安全，这意味着您可以在不受内部信号处理程序限制的情况下使用它。另一方面，互斥体确实有一个无法用信号量实现的功能：鲁棒互斥体属性，它允许您创建互斥体，允许其他线程/进程在线程发生异常时检测并恢复/进程在持有互斥体时终止（而不仅仅是死锁）。
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
Ntimes to wait forNthreads 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 amongNequivalent 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).
因为这就是互斥信号量的用途，互斥（排除除此线程之外的所有其他线程）。
它锁定资源，以便特定的执行线程可以不受限制地访问该资源。
“常规”信号量（如
sem_wait/sem_post）是计数信号量。您可以根据互斥指定有N个可用资源，而不是只有一个。您当然可以使用常规信号量来模拟互斥信号量，但您会失去一些保护（例如确保只有所有者可以解锁它）。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 areNresources 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).