关于pthread_mutex_lock和pthread_mutex_unlock的一些问题

当一个线程获得了锁并执行下面的代码时，线程是否可以使用return语句来解锁它所获取的锁？一些这样的代码。关于pthread_mutex_lock和pthread_mutex_unlock的一些问题

static pthread_mutex_t mutex; 

    int foo() 
    { 
     pthread_mutex_lock(mutex); 

     ......... 
     execute some code here and some errors happen 
       return -1;// but without pthread_mutex_unlock 

     pthread_mutex_unlock(mutext) 
     return 0; 
    }

某些错误发生在pthread_mutex_unlock语句和线程返回给被调用者之前。线程是否会返回其他线程的mutext锁而不执行pthread_mutex_unlock？

来源

2010-09-13 terry

如果它自动解锁，如何从锁定互斥锁的函数返回？你怎么能写一个函数，其目的是选择正确的互斥锁并锁定它？ – 2011-08-30 13:09:27

不，它不会自动解锁互斥锁。如果互斥锁已被该函数锁定，则必须在错误路径中明确呼叫pthread_mutex_unlock()。

来源

2010-09-13 07:10:43 caf

不，锁不会自动释放。这就是为什么在C++代码中，通常使用资源获取初始化（RAII），它利用构造/销毁来确保每个对锁定函数的调用都有相应的解锁呼叫。但是，如果您正在编写纯C代码，则需要确保在返回之前即使在错误情况下解锁互斥锁。

请注意，你可以让你的编码通过执行以下操作更容易些：

static inline int some_function_critical_section_unsynchronized(void) { 
     // ... 
    } 
    int some_function(void) { 
     int status = 0; 
     pthread_mutex_lock(mutex); 
     status = some_function_critical_section_unsynchronized(); 
     pthread_mutex_unlock(mutex); 
     return status; 
    }

换句话说，如果你能逻辑分成更小的功能，你可以梳理出锁定来自你的逻辑的代码。当然，有时候这是不可能的（比如，当以这种方式进行编码会使关键部分太大，并且对于性能而言，需要不太可读的形式）。

如果您可以使用C++，我强烈建议使用boost :: thread和boost :: scoped_lock来确保获取的互斥量在使用超出范围时自动释放。

来源

2010-09-13 07:11:03

关于pthread_mutex_lock和pthread_mutex_unlock的一些问题

回答

相关问题