自旋锁和读写自旋锁.docxVIP

自旋锁分类：?疯狂内核之同步与互斥2010-05-18 19:59?395人阅读?评论(0)?收藏?举报加锁（locking）是一种广泛应用的同步技术。当内核控制路径必须访问共享数据结构或进入临界区时，就需要为自己获取一把“锁”。由锁机制保护的资源非常类似于限制于房间内的资源，当某人进入房间时，就把门锁上。如果内核控制路径希望访问资源，就试图获取钥匙“打开门”。当且仅当资源空闲时，它才能成功。然后，只要它还想使用这个资源，门就依然锁着。当内核控制路径释放了锁时，门就打开，另一个内核控制路径就可以进入房间。下图显示了锁的使用。5个内核控制路径（P0，PI，P2，P3和P4）试图访问两个临界区（C1和C2）。内核控制路径P0正在C1中，而P2和P4正等待进人C1。同时，P1正在C2中，而P3正在等待进入C2。注意P0和P1可以并行运行。临界区C3的锁现在打开着，因为没有内核控制路径需要进人C3。??Linux锁的应用之一在多处理器环境中，取名叫自旋锁（spin lock）。如果内核控制路径发现自旋锁“开着”，就获取锁并继续自己的执行。相反，如果内核控制路径发现锁由运行在另一个CPU上的内核控制路径“锁着”，就在周围“旋转”，反复执行一条紧凑的循环指令，直到锁被释放。自旋锁的循环指令表示“忙等”。即使等待的内核控制路径无事可做（除了浪费时间），它也在CPU上保持运行。不过，自旋锁通常非常方便，因为很多内核资源只锁1毫秒的时间片段；所以说，等待自旋锁的释放不会消耗太多CPU的时间。一般来说，由自旋锁所保护的每个临界区都是禁止内核抢占的。在单处理器系统上，这种锁本身并不起锁的作用，自旋锁技术仅仅是用来禁止或启用内核抢占。请注意，在自旋锁忙等期间，因为并没有进入临界区，所以内核抢占还是有效的，因此，等待自旋锁释放的进程有可能被更高优先级的所取代。这种设计是合理的，因为不能因为占用CPU太久而使系统死锁。?在Linux中，每个自旋锁都用spinlock_t结构表示：typedef struct {??? raw_spinlock_t raw_lock;#if defined(CONFIG_PREEMPT) defined(CONFIG_SMP)??? unsigned int break_lock;#endif#ifdef CONFIG_DEBUG_SPINLOCK??? unsigned int magic, owner_cpu;??? void *owner;#endif#ifdef CONFIG_DEBUG_LOCK_ALLOC??? struct lockdep_map dep_map;#endif} spinlock_t;typedef struct {??? volatile unsigned int slock;} raw_spinlock_t;其中包含两个重要的字段意义如下：slock：该字段表示自旋锁的状态：值为1表示“未加锁”状态，而任何负数和0都表示“加锁”状态。break_lock：表示进程正在忙等自旋锁（只在内核支持SMP和内核抢占的情况下使用该标志）。内核提供六个宏用于初始化、测试及设置自旋锁。所有这些宏都是基于原子操作的，这样可以保证即使有多个运行在不同CPU上的进程试图同时修改自旋锁，自旋锁也能够被正确地更新。?1、spin_lock_init —— 初始化自旋锁，并把自旋锁的lock-raw_lock置为1（未锁）# define spin_lock_init(lock)??? ??? ??? ??? ??? /do {??? ??? ??? ??? ??? ??? ??? ??? /??? static struct lock_class_key __key;??? ??? ??? /??? ??? ??? ??? ??? ??? ??? ??? /??? __spin_lock_init((lock), #lock, __key);??? ??? /} while (0)void __spin_lock_init(spinlock_t *lock, const char *name,??? ??? ????? struct lock_class_key *key){#ifdef CONFIG_DEBUG_LOCK_ALLOC??? /*??? ?* Make sure we are not reinitializing a held lock:??? ?*/??? debug_check_no_locks_freed((void *)lock, sizeof(*lock));??? lockdep_init_map(lock-dep_map, name, key, 0);#endif??? lock-