关于 windows 互斥锁CRITICAL_SECTION 多次加锁,需要多少释放的问题

我们程序里,有时某个线程会对锁,连续加两次锁,我以前以为只要释放一次,就会释放该临界区,可不是这样的。应该几次加锁,就应该几次释放锁。

 

CRITICAL_SECTION  mylock;

DWORD WINAPI ThreadFunc3(LPVOID lpParameter)
{
 EnterCriticalSection(&mylock);
  cout << "线程3 第一次加锁成功" << endl;
 EnterCriticalSection(&mylock);
  cout << "线程3 第二次加锁成功" << endl;
 {
  EnterCriticalSection(&mylock);
  cout << "线程3 第二次加锁成功" << endl;
  LeaveCriticalSection(&mylock);
  cout << "线程3 第二次解锁成功" << endl;
 }
  LeaveCriticalSection(&mylock);
  cout << "线程3 第一次解锁成功" << endl;

 return 0;
}

DWORD WINAPI ThreadFunc4(LPVOID lpParameter)
{
 Sleep(1000);
 EnterCriticalSection(&mylock);
 cout << "线程4 加锁成功" << endl;
 LeaveCriticalSection(&mylock);
 return 0;
}

 

在线程3中我们连接两次加了锁,如果我们只释放一次,线程4永远也加不起锁;

只有线程3加了两次锁,也释放了两次,线程4才可加起锁。

故,应该有几次加锁,就应该有几次释放锁。

我想原因可能是这样的,锁里面应该有一个引用计数在里面,在A线程中,对某一锁加锁一次,引用计数加1,对锁解锁一次,引用计数减1,当为0时,才会释放该临界区,线程B才可加上该互斥锁。

### FreeRTOS 中互斥锁的工作原理 #### 互斥锁的作用 互斥锁主要用于保护共享资源,防止多个任务同时访问同一资源。通过使用互斥锁,可以确保每只有一个任务能访问该资源,从而避免数据竞争和其他同步问题[^5]。 #### 获取与释放机制 当一个任务尝试获取互斥锁时,如果此时互斥锁已被其他任务持有,则请求获取的任务会被阻塞并进入等待状态直到当前持有者释放互斥锁。值得注意的是,在FreeRTOS中存在一种特殊现象:任何任务都可以调用API来解锁某个已经被锁定的互斥量,而不仅仅限于最初加锁的那个任务;这实际上是一种编程上的约定而非强制性的技术限制[^2]。 #### 实现细节 为了实现上述功能,FreeRTOS中的互斥锁内部维护了一个计数器以及指向拥有者的指针。每当有新任务成功获得互斥锁时,计数器增加,并记录下占有此锁的任务ID。相反地,当执行解除操作时则减少计数值直至归零表示完全开放给下一个申请者。这种设计允许嵌套式的多次占用相同互斥对象而不至于造成死锁状况发生。 ```c // 创建互斥锁的例子 SemaphoreHandle_t xMutex; void setup() { // 初始化互斥锁 xMutex = xSemaphoreCreateMutex(); if (xMutex != NULL) { // 成功创建互斥锁... } } // 使用互斥锁保护临界区 void criticalSectionAccess(void){ if( xSemaphoreTake( xMutex, portMAX_DELAY ) == pdTRUE ){ /* Critical section begins */ // 访问受保护的资源共享部分 /* End of the critical section so release the mutex. */ xSemaphoreGive( xMutex ); }else{ // 进入不到临界区处理逻辑 } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值