当一个线程由2个线程共享并由pthread_mutex_lock保护时，优先处理一个线程来处理变量

如何解决当一个线程由2个线程共享并由pthread_mutex_lock保护时，优先处理一个线程来处理变量

有人可以建议使用pthread_mutex_lock优化以下应用程序代码吗？

让我描述一下情况：
我有2个线程共享一个全局共享内存变量。这两个函数中的变量shmPtr->status受互斥锁保护。尽管task1函数的“ for循环”内部有一个sleep(1/2)，但是当需要时我无法访问task2中的shmPtr->status，而不得不等到task1中的“ for循环”完成功能。 shmPtr->status大约需要50秒才能用于task2函数。

我想知道为什么尽管有sleep(1/2)行，task1函数仍未释放互斥锁。我不想等待在task2函数中处理shmPtr->status。请指教。

 thr_id1 = pthread_create ( &p_thread1,NULL,(void *)execution_task1,NULL );
 thr_id2 = pthread_create ( &p_thread2,(void *)execution_task2,NULL );  

 void execution_task1()
 {
     for(int i = 0;i < 100;i++) 
     {
          //100 lines of application code running here
          pthread_mutex_lock(&lock);  
                shmPtr->status = 1;  //shared memory variable 
         pthread_mutex_unlock(&lock);
         sleep(1/2);
     }
 }

 void execution_task2()
 {
         //100 lines of application code running here
         pthread_mutex_lock(&lock);  
                shmPtr->status = 0;  //shared memory variable
         pthread_mutex_unlock(&lock);
         sleep(1/2);
 }

关于， NK

解决方法

我想知道为什么task1函数即使在睡眠（1/2）时也不会释放互斥锁。

没有理由认为示例中运行execution_task1()的线程无法释放互斥量，尽管您可以确定是否正确测试了其pthread_mutex_unlock()调用的返回值。相反，潜在的问题是它在争用它的任何其他线程有机会获取互斥之前重新获取互斥。

对sleep(1/2)的调用无法有效地阻止这种情况似乎是合理的。 1/2是一个整数除法，求值为0，因此您正在执行sleep(0)。这可能根本不会导致调用线程挂起，甚至可能不会导致线程放弃CPU。

更一般地说，sleep()从来都不是解决任何线程同步问题的好方法。

但是，如果您正在多核系统上运行，即使您不是在多核系统上运行，那么如果该函数确实确实在释放内核之间执行了一百行代码，则似乎不太可能通过这种机制冻结其他线程。互斥并尝试再次锁定它。如果那是您认为所看到的，那么请加倍努力。

如果确实需要强制执行线程以使其他人有机会获取互斥量，则可以按照Implementing a FIFO mutex in pthreads中所述建立公平的排队系统。但是，对于诸如dsecribe的情况，由于一个长时间运行的线程有时需要屈服于其他更快的任务，您可以考虑引入一个条件变量，长时间运行的线程可以在该条件变量上挂起，而 atomic 计数器，通过它可以确定是否应该这样做：

#include <stdatomic.h>

// ...

pthread_cond_t yield_cv = PTHREAD_COND_INITIALIZER;
_Atomic unsigned int waiting_thread_count = ATOMIC_VAR_INIT(0);

void execution_task1() {
    for (int i = 0; i < 100; i++) {
        // ...

        pthread_mutex_lock(&lock);
        if (waiting_thread_count > 0) {
            pthread_cond_wait(&yield_cv,&lock);
            // spurrious wakeup ok
        }

        // ... critical section ...

        pthread_mutex_unlock(&lock);
    }
}

void execution_task2() {
    // ...

    waiting_thread_count += 1;  // Atomic get & increment; safe w/o mutex
    pthread_mutex_lock(&lock);  
    waiting_thread_count -= 1;
    pthread_cond_signal(&yield_cv);  // no problem if no-one is presently waiting

    // ... critical section ...

    pthread_mutex_unlock(&lock);
}

使用原子计数器使程序不必使用自己的互斥量来保护该计数器，这可能会转移问题而不是解决问题。这样一来，线程就可以使用计数器来发出即将进行的获取互斥量尝试的信号。然后，该意图对于另一个线程是可见的，因此它可以挂在CV上，以允许另一个获取互斥体。

然后，短时间运行的线程通过递减计数器来确认获取互斥量。他们必须在释放互斥锁之前执行此操作，否则长时间运行的线程可能会循环运行，获取互斥锁并在递减计数器之前读取计数器，从而在无法期望其他信号时错误地阻塞了CV。

尽管CV可能会受到强烈的唤醒，但这对于这种方法并不构成严重的问题。如果长时间运行的线程从等待CV的过程中突然醒来，则发生的最坏情况是它再次对其主循环执行了一次迭代，然后再次等待。