There is new implementaion in newer kernel (my kernel version is
2.6.27). Compared to the old implementaion which uses binary
semaphore, there are some new features:
- '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
But in my test, I try to lock mutex in one thread, and unlock it in
the other thread. There is nothing wrong happens. It works just like
semaphore. I have had CONFIG_DEBUG_MUTEXES turned on.
The two threads are mostly like this:
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;
}
I debug it and find the debug_locks = 0. Is this why there is no
warning message and how turn it on? (I also had CONFIG_LOCKDEP_SUPPORT
on.)
--
Xie Gang
2009/6/1 л?? <[email protected]>:
> I debug it and find the debug_locks = 0. Is this why there is no
> warning message and how turn it on? (I also had CONFIG_LOCKDEP_SUPPORT
> on.)
Please confirm CONFIG_PROVE_LOCKING is enabled.
Thanks,
--
Lei Ming
2009/6/1 Ming Lei <[email protected]>:
> 2009/6/1 л?? <[email protected]>:
>> I debug it and find the debug_locks = 0. Is this why there is no
>> warning message and how turn it on? (I also had CONFIG_LOCKDEP_SUPPORT
>> on.)
>
> Please confirm CONFIG_PROVE_LOCKING is enabled.
It still does not work. No warning is found. It still behaves as
binary semophore.
Thanks,
>
> Thanks,
> --
> Lei Ming
>
--
Xie Gang
On Mon, Jun 1, 2009 at 5:06 PM, Xiaotian Feng <[email protected]> wrote:
>
>
> On Mon, Jun 1, 2009 at 2:49 PM, л?? <[email protected]> wrote:
>>
>> There is new implementaion in newer kernel (my kernel version is
>> 2.6.27). Compared to the old implementaion which uses binary
>> semaphore, there are some new features:
>> - '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
>>
>> But in my test, I try to lock mutex in one thread, and unlock it in
>> the other thread. There is nothing wrong happens. It works just like
>> semaphore. I have had CONFIG_DEBUG_MUTEXES turned on.
>> The two threads are mostly like this:
>> 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);
I typied wrong funcion. Actually, I unlock mutex with mutex_unlock here.
>
> unlock here?
yes.
>>
>> }
>> return 0;
>> }
>>
>> I debug it and find the debug_locks = 0. Is this why there is no
>> warning message and how turn it on? (I also had CONFIG_LOCKDEP_SUPPORT
>> on.)
>>
>>
>> --
>> Xie Gang
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Xie Gang