首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Linux驱动必学知识点-内核互斥锁

mutex的语义相对于信号量要简单轻便一些,在锁争用激烈的测试场景下,mutex比信号量执行速度更快,可扩展性更好,另外mutex数据结构的定义比信号量小。

mutex的优点

mutex和信号量相比要高效的多:

mutex最先实现自旋等待机制

mutex在睡眠之前尝试获取锁

mutex实现MCS所来避免多个CPU争用锁而导致CPU高速缓存颠簸现象。

mutex的使用注意事项:

同一时刻只有一个线程可以持有mutex。

只有锁持有者可以解锁。不能再一个进程中持有mutex,在另外一个进程中释放他。

不允许递归地加锁和解锁。

当进程持有mutex时,进程不可以退出。

mutex必须使用官方API来初始化。

mutex可以睡眠,所以不允许在中断处理程序或者中断下半部中使用,例如tasklet、定时器等。

目录:

/linux/include/linux/mutex.h

/*

* Simple, straightforward mutexes with strict semantics:

*

* - only one task can hold the mutex at a time

* - only the owner can unlock the mutex

* - multiple unlocks are not permitted

* - recursive locking is not permitted

* - a mutex object must be initialized via the API

* - a mutex object must not be initialized via memset or copying

* - task may not exit with mutex held

* - memory areas where held locks reside must not be freed

* - held mutexes must not be reinitialized

* - mutexes may not be used in hardware or software interrupt

*   contexts such as tasklets and timers

*

* These semantics are fully enforced when DEBUG_MUTEXES is

* enabled. Furthermore, besides enforcing the above rules, the mutex

* debugging code also implements a number of additional features

* that make lock debugging easier and faster:

*

* - uses symbolic names of mutexes, whenever they are printed in debug output

* - point-of-acquire tracking, symbolic lookup of function names

* - list of all locks held in the system, printout of them

* - owner tracking

* - detects self-recursing locks and prints out all relevant info

* - detects multi-task circular deadlocks and prints out all affected

*   locks and tasks (and only those tasks)

*/

struct mutex {

/* 1: unlocked, 0: locked, negative: locked, possible waiters */

atomic_t    count;

spinlock_t    wait_lock;

struct list_head  wait_list;

#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP)

struct task_struct  *owner;

#endif

#ifdef CONFIG_MUTEX_SPIN_ON_OWNER

void      *spin_mlock;  /* Spinner MCS lock */

#endif

#ifdef CONFIG_DEBUG_MUTEXES

const char     *name;

void      *magic;

#endif

#ifdef CONFIG_DEBUG_LOCK_ALLOC

struct lockdep_map  dep_map;

#endif

};

作用及访问规则:

互斥锁主要用于实现内核中的互斥访问功能。内核互斥锁是在原子 API 之上实现的,但这对于内核用户是不可见的。

对它的访问必须遵循一些规则:同一时间只能有一个任务持有互斥锁,而且只有这个任务可以对互斥锁进行解锁。互斥锁不能进行递归锁定或解锁。一个互斥锁对象必须通过其API初始化,而不能使用memset或复制初始化。一个任务在持有互斥锁的时候是不能结束的。互斥锁所使用的内存区域是不能被释放的。使用中的互斥锁是不能被重新初始化的。并且互斥锁不能用于中断上下文。

互斥锁比当前的内核信号量选项更快,并且更加紧凑。

互斥体的使用

初始化

静态定义如下:

DEFINE_MUTEX(name);

动态初始化mutex,如下:

mutex_init(&mutex);

具体实现如下:

#define mutex_init(mutex) \

do {       \

static struct lock_class_key __key;  \

\

__mutex_init((mutex), #mutex, &__key);  \

} while (0)

void

__mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)

{

atomic_set(&lock->count, 1);

spin_lock_init(&lock->wait_lock);

INIT_LIST_HEAD(&lock->wait_list);

mutex_clear_owner(lock);

#ifdef CONFIG_MUTEX_SPIN_ON_OWNER

lock->spin_mlock = NULL;

#endif

debug_mutex_init(lock, name, key);

}

申请互斥锁

mutex操作列表如下:

mutex的简洁性和高效性源自于相比使用信号量更多的受限性。它不同于信号量,因为mutex仅仅实现了Dijkstra设计初衷中的最基本的行为。因此mutex的使用场景相对而言更严格。

(1)代码:linux/kernel/mutex.c

void inline fastcall __sched mutex_lock(struct mutex *lock);

//获取互斥锁。

实际上是先给count做自减操作,然后使用本身的自旋锁进入临界区操作。首先取得count的值,在将count置为-1,判断如果原来count的置为1,也即互斥锁可以获得,则直接获取,跳出。否则进入循环反复测试互斥锁的状态。在循环中,也是先取得互斥锁原来的状态,在将其之为-1,判断如果可以获取(等于1),则退出循环,否则设置当前进程的状态为不可中断状态,解锁自身的自旋锁,进入睡眠状态,待被在调度唤醒时,再获得自身的自旋锁,进入新一次的查询其自身状态(该互斥锁的状态)的循环。

(2)具体参见linux/kernel/mutex.c

int fastcall __sched mutex_lock_interruptible(struct mutex *lock);

和mutex_lock()一样,也是获取互斥锁。在获得了互斥锁或进入睡眠直到获得互斥锁之后会返回0。如果在等待获取锁的时候进入睡眠状态收到一个信号(被信号打断睡眠),则返回_EINIR。

(3)具体参见linux/kernel/mutex.c

int fastcall __sched mutex_trylock(struct mutex *lock);

试图获取互斥锁,如果成功获取则返回1,否则返回0,不等待。

释放互斥锁

具体参见linux/kernel/mutex.c

void fastcall mutex_unlock(struct mutex *lock);

释放被当前进程获取的互斥锁。该函数不能用在中断上下文中,而且不允许去释放一个没有上锁的互斥锁。

互斥锁试用注意事项

任何时刻中只有一个任务可以持有mutex, 也就是说,mutex的使用计数永远是1

给mutex锁者必须负责给其再解锁——你不能在一个上下文中锁定一个mutex,而在另 一个上下文中给它解锁。这个限制使得mutex不适合内核同用户空间复杂的同步场景。最 常使用的方式是:在同一上下文中上锁和解锁。

递归地上锁和解锁是不允许的。也就是说,你不能递归地持有同一个锁,同样你也不能再去解锁一个已经被解开的mutex

当持有一个mutex时 ,进程不可以退出

mutex不能在中断或者下半部中使用,即使使用mutex_trylock()也不行

mutex只能通过官方API管理:它只能使用上节中描述的方法初始化,不可被拷贝、手动 初始化或者重复初始化

信号量和互斥体

互斥体和信号量很相似,内核中两者共存会令人混淆。所幸,它们的标准使用方式都有简单规范:除非mutex的某个约束妨碍你使用,否则相比信号量要优先使用mutex。当你写新代码时,只有碰到特殊场合(一般是很底层代码)才会需要使用信号量。因此建议 选mutex。如果发现不能满足其约束条件,且没有其他别的选择时,再考虑选择信号量

自旋锁和互斥体使用场合

了解何时使用自旋锁,何时使用互斥体(或信号量)对编写优良代码很重要,但是多数情况下,并不需要太多的考虑,因为在中断上下文中只能使用自旋锁,而在任务睡眠时只能使用互斥体。

下面总结一下各种锁的需求情况

互斥锁锁定和解锁使用实例

使用方法如下:

1. struct mutex mutex;

2. mutex_init(&mutex); /*定义*/

3. //加锁

4. mutex_lock(&mutex);

5.

6. //临界区

7.

8. //解锁

9. mutex_unlock(&mutex);

可以看出,互斥体就是一个简化版的信号量,因为不再需要管理任何使用计数。

下面网卡DM9000的驱动,其中写入eeprom的操作试用了mutex机制:

static void

dm9000_write_eeprom(board_info_t *db, int offset, u8 *data)

{

unsigned long flags;

if (db->flags & DM9000_PLATF_NO_EEPROM)

return;

mutex_lock(&db->addr_lock);

spin_lock_irqsave(&db->lock, flags);

iow(db, DM9000_EPAR, offset);

iow(db, DM9000_EPDRH, data[1]);

iow(db, DM9000_EPDRL, data[0]);

iow(db, DM9000_EPCR, EPCR_WEP | EPCR_ERPRW);

spin_unlock_irqrestore(&db->lock, flags);

dm9000_wait_eeprom(db);

mdelay(1); /* wait at least 150uS to clear */

spin_lock_irqsave(&db->lock, flags);

iow(db, DM9000_EPCR, 0);

spin_unlock_irqrestore(&db->lock, flags);

mutex_unlock(&db->addr_lock);

}

可以看到每次驱动向eeprom写入数据(访问临界资源),都需要首先获得该资源对应的互斥锁db->addr_lock,并且使用完毕必须释放该锁。

  • 发表于:
  • 原文链接https://page.om.qq.com/page/OOcUtP7Aro3pO_gnb20R6dPA0
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券