【Linux驱动篇】同步机制(2)— 互斥锁
linux-dash
A beautiful web dashboard for Linux
项目地址:https://gitcode.com/gh_mirrors/li/linux-dash
免费下载资源
·
一、概述
互斥锁struct mutex是内核访问临界区上锁的另一种方式,不同于自旋锁,在互斥锁上锁期间,另一个进程获取不到锁,可能会导致睡眠,直到前一个进程释放了互斥锁,后一个进程才会被唤醒,并获取该互斥锁。
由于互斥锁可能导致睡眠,所以不能在中断、tasklet和内核定时器中使用。
二、互斥锁
//in include/linux/mutex.h
struct mutex {
atomic_long_t owner;
spinlock_t wait_lock;
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
struct optimistic_spin_queue osq; /* Spinner MCS lock */
#endif
struct list_head wait_list;
#ifdef CONFIG_DEBUG_MUTEXES
void *magic;
#endif
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
};
struct mutex mutex_lock;
//初始化互斥锁
mutex_init(&mutex_lock);
//互斥锁加锁
mutex_lock(&mutex_lock);
mutex_lock_interruptible(&mutex_lock);
mutex_trylock(&mutex_lock);
//互斥锁解锁
mutex_unlock(&mutex_lock);
mutex_lock引起的睡眠不能被打断,而mutex_lock_interruptible可以被打断。mutex_trylock(&mutex_lock)是非阻塞的,若加锁成功返回1,失败返回0。
使用互斥锁的注意事项:
- 由于互斥锁可能导致睡眠,进而引起CPU调度,发生进程上下文的切换,所以消耗的资源是比较多的,只有当进程占用资源时间较长时,才选择互斥锁。反之可选择自旋锁
- 互斥锁不能在中断、软中断、tasklet和内核定时器等不允许睡眠的场景下使用(定时器处理函数是作为软中断在底半部执行的)
- 互斥锁无法递归加锁,无法重复解锁,这一点跟自旋锁也是一样
三、源码分析
#define MUTEX_FLAG_WAITERS 0x01
#define MUTEX_FLAG_HANDOFF 0x02
#define MUTEX_FLAG_PICKUP 0x04
void __sched mutex_lock(struct mutex *lock)
{
might_sleep();
if (!__mutex_trylock_fast(lock))
__mutex_lock_slowpath(lock);
}
static __always_inline bool __mutex_trylock_fast(struct mutex *lock)
{
unsigned long curr = (unsigned long)current;
if (!atomic_long_cmpxchg_acquire(&lock->owner, 0UL, curr))
return true;
return false;
}
static noinline void __sched
__mutex_lock_slowpath(struct mutex *lock)
{
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, NULL, _RET_IP_);
}
static int __sched
__mutex_lock(struct mutex *lock, long state, unsigned int subclass,
struct lockdep_map *nest_lock, unsigned long ip)
{
return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL, false);
}
*
* Lock a mutex (possibly interruptible), slowpath:
*/
static __always_inline int __sched
__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
struct lockdep_map *nest_lock, unsigned long ip,
struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
{
struct mutex_waiter waiter;
bool first = false;
struct ww_mutex *ww;
int ret;
might_sleep();
ww = container_of(lock, struct ww_mutex, base);
if (use_ww_ctx && ww_ctx) {
if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
return -EALREADY;
}
preempt_disable();
mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
if (__mutex_trylock(lock) ||
mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, NULL)) {
/* got the lock, yay! */
lock_acquired(&lock->dep_map, ip);
if (use_ww_ctx && ww_ctx)
ww_mutex_set_context_fastpath(ww, ww_ctx);
preempt_enable();
return 0;
}
spin_lock(&lock->wait_lock);
/*
* After waiting to acquire the wait_lock, try again.
*/
if (__mutex_trylock(lock)) {
if (use_ww_ctx && ww_ctx)
__ww_mutex_wakeup_for_backoff(lock, ww_ctx);
goto skip_wait;
}
debug_mutex_lock_common(lock, &waiter);
debug_mutex_add_waiter(lock, &waiter, current);
lock_contended(&lock->dep_map, ip);
if (!use_ww_ctx) {
/* add waiting tasks to the end of the waitqueue (FIFO): */
list_add_tail(&waiter.list, &lock->wait_list);
#ifdef CONFIG_DEBUG_MUTEXES
waiter.ww_ctx = MUTEX_POISON_WW_CTX;
#endif
} else {
/* Add in stamp order, waking up waiters that must back off. */
ret = __ww_mutex_add_waiter(&waiter, lock, ww_ctx);
if (ret)
goto err_early_backoff;
waiter.ww_ctx = ww_ctx;
}
waiter.task = current;
if (__mutex_waiter_is_first(lock, &waiter))
__mutex_set_flag(lock, MUTEX_FLAG_WAITERS);
set_current_state(state);
for (;;) {
/*
* Once we hold wait_lock, we're serialized against
* mutex_unlock() handing the lock off to us, do a trylock
* before testing the error conditions to make sure we pick up
* the handoff.
*/
if (__mutex_trylock(lock))
goto acquired;
/*
* Check for signals and wound conditions while holding
* wait_lock. This ensures the lock cancellation is ordered
* against mutex_unlock() and wake-ups do not go missing.
*/
if (unlikely(signal_pending_state(state, current))) {
ret = -EINTR;
goto err;
}
if (use_ww_ctx && ww_ctx && ww_ctx->acquired > 0) {
ret = __ww_mutex_lock_check_stamp(lock, &waiter, ww_ctx);
if (ret)
goto err;
}
spin_unlock(&lock->wait_lock);
schedule_preempt_disabled();
/*
* ww_mutex needs to always recheck its position since its waiter
* list is not FIFO ordered.
*/
if ((use_ww_ctx && ww_ctx) || !first) {
first = __mutex_waiter_is_first(lock, &waiter);
if (first)
__mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
}
set_current_state(state);
/*
* Here we order against unlock; we must either see it change
* state back to RUNNING and fall through the next schedule(),
* or we must see its unlock and acquire.
*/
if (__mutex_trylock(lock) ||
(first && mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, &waiter)))
break;
spin_lock(&lock->wait_lock);
}
spin_lock(&lock->wait_lock);
acquired:
__set_current_state(TASK_RUNNING);
mutex_remove_waiter(lock, &waiter, current);
if (likely(list_empty(&lock->wait_list)))
__mutex_clear_flag(lock, MUTEX_FLAGS);
debug_mutex_free_waiter(&waiter);
skip_wait:
/* got the lock - cleanup and rejoice! */
lock_acquired(&lock->dep_map, ip);
if (use_ww_ctx && ww_ctx)
ww_mutex_set_context_slowpath(ww, ww_ctx);
spin_unlock(&lock->wait_lock);
preempt_enable();
return 0;
err:
__set_current_state(TASK_RUNNING);
mutex_remove_waiter(lock, &waiter, current);
err_early_backoff:
spin_unlock(&lock->wait_lock);
debug_mutex_free_waiter(&waiter);
mutex_release(&lock->dep_map, 1, ip);
preempt_enable();
return ret;
}
- 首先mutex_lock调用__mutex_trylock_fast------>atomic_long_cmpxchg_acquire获取互斥锁,该函数将lock->owner和0UL进行比较,如果相等(该互斥锁没有被进程占用),那么将第三个参数赋值给第一个参数,也就是lock->owner=curr,如果不相等,说明已经有进程加锁占用了,该函数什么都不执行,直接返回lock->owner。
- 若步骤一加锁成功,则直接返回结果;如果步骤一加锁失败,继续执行__mutex_lock_slowpath尝试加锁,核心函数是__mutex_lock_common。
__mutex_lock_slowpath----->
__mutex_lock----------------->
__mutex_lock_common—> - __mutex_lock_common里,首先执行preempt_disbale函数关闭抢占(只在加锁过程中关闭抢占),然后执行两个核心函数,其一是__mutex_trylock—>__mutex_trylock_or_owner,其二是mutex_optimistic_spin,前者尝试加锁,后者尝试自旋等待。
- __mutex_trylock_or_owner中,取了lock->owner的持有者赋值给owner变量,owner变量由’struct task_struct * '指针,NULL 表示不拥有,以及低三位的标志状态组成。
- Bit0 MUTEX_FLAG_WAITERS,表示当前有锁的等待者
- Bit1 MUTEX_FLAG_HANDOFF,表示解锁需要将锁交给top-waiter
- Bit2 MUTEX_FLAG_PICKUP,表示已完成handoff标志位的确认。
__mutex_trylock_or_owner中判断了当前进程和锁的持有者进程是否相等,以及当前锁持有者的bit2是否置位,如果条件不满足就会继续执行加锁函数。__mutex_trylock执行失败则继续执行第二个函数:mutex_optimistic_spin。
/*
* Trylock variant that retuns the owning task on failure.
*/
static inline struct task_struct *__mutex_trylock_or_owner(struct mutex *lock)
{
unsigned long owner, curr = (unsigned long)current;
owner = atomic_long_read(&lock->owner);
for (;;) { /* must loop, can race against a flag */
unsigned long old, flags = __owner_flags(owner);
unsigned long task = owner & ~MUTEX_FLAGS;
if (task) {
if (likely(task != curr))
break;
if (likely(!(flags & MUTEX_FLAG_PICKUP)))
break;
flags &= ~MUTEX_FLAG_PICKUP;
} else {
#ifdef CONFIG_DEBUG_MUTEXES
DEBUG_LOCKS_WARN_ON(flags & MUTEX_FLAG_PICKUP);
#endif
}
/*
* We set the HANDOFF bit, we must make sure it doesn't live
* past the point where we acquire it. This would be possible
* if we (accidentally) set the bit on an unlocked mutex.
*/
flags &= ~MUTEX_FLAG_HANDOFF;
old = atomic_long_cmpxchg_acquire(&lock->owner, owner, curr | flags);
if (old == owner)
return NULL;
owner = old;
}
return __owner_task(owner);
}
进入mutex_optimistic_spin函数时,waiter参数为NULL,该函数会先判断当前请求锁的进程能否进入到自旋等待状态,如果可以才会去执行osq_lock,并循环尝试加锁和自旋,若失败则返回进入睡眠状态
- 如果以上尝试加锁和自旋都失败了,接下来就是进入睡眠
将当前进程加入lock->wait_list等待队列,并设置bit0和bit1标志位,告知系统当前队列有等待者
调用schedule_preempt_disabled进行系统调度
当本进程被唤醒时,判断了如果是等待队列里的第一个,就设置handoff标志,标志着锁释放后,先给本进程加锁
然后本进程调用__mutex_trylock加锁,如果加锁成功则跳出循环,加锁结束,将本进程从互斥锁等待队列移除等等,做一些清除工作。
No pains, no gains
GitHub 加速计划 / li / linux-dash
6
1
下载
A beautiful web dashboard for Linux
最近提交(Master分支:3 个月前 )
186a802e
added ecosystem file for PM2 4 年前
5def40a3
Add host customization support for the NodeJS version 4 年前
更多推荐
已为社区贡献1条内容
所有评论(0)