请教较新版本内核中mutex的使用

xiegang112

在较新版本中，如2.6.27中，内核有专门的metux子系统，而不是之前使用的binary semaphore.
在文档中，有这样的描述：
'struct mutex' semantics are well-defined and are enforced if
   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have
   virtually no debugging code or instrumentation. The mutex subsystem
   checks and enforces the following rules:

   * - 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

为了测试这些metux的feature，我把内核的CONFIG_DEBUG_MUTEXES 打开并打开了CONFIG_LOCKDEP_SUPPORT.但是并没有得到描述中的结果。其中，关于metex是否能被不同进程lock/unlock的问题，我有以下两个内核线程：
struct mutex mutex;

static int mysthread1(void * data){
  int i;
  i= 5;  
  while(i -- > 0){
                mutex_lock(&mutex);
    printk("this is thread1\n");
    msleep(5000);
  }
        return 0;
}

static int mysthread2(void * data){
  int i;
  i= 5;  
  while(i -- > 0){
    printk("this is thread2\n");
    msleep(5000);
                mutex_lock(&mutex);
  }
        return 0;
}

在模块中启动两个线程后，并没有出现什么异常，每个线程都输出了5条信息。因此这个和文档描述矛盾。哪个兄弟能解释下？
谢谢

yjh777

锁在哪初始化的啊？

xiegang112

在init函数初始化的。上面没有写出来，不好意思。
看了下代码，并调试了下。
在__mutex_unlock_common_slowpath中（由mutex_unlock调用）会调用检查mutex那些feathure的函数：debug_mutex_unlock
void debug_mutex_unlock(struct mutex *lock)
{
        if (unlikely(!debug_locks))
                return;

        DEBUG_LOCKS_WARN_ON(lock->magic != lock);
        DEBUG_LOCKS_WARN_ON(lock->owner != current_thread_info());
        DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
        DEBUG_LOCKS_WARN_ON(lock->owner != current_thread_info());
}
我调试到这里时，发现debug_locks为0.
而debug_locks在debug_locks.c中赋值：int debug_locks = 1;
难道有些config选项不对？

hptsf

结论是啥啊？
后续呢？

Tinnal

真不明白你想干嘛。
首先，“关于metex是否能被不同进程lock/unlock的问题”，这个问题你前文并没提到呀。在内核态对调度而言本来就没有进程/线程的区别。如果不能被多个执行流同时执行，那要锁来干嘛。
其次，你这个案例，不是明显会死锁吗？