Linux pthread mutex deadlock sometimes get assert, while sometimes not
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Linux pthread mutex deadlock sometimes get assert, while sometimes not
I encountered an odd question about linux mutex lock, with Fedora 16 x64 as the development platform.
Code:
pthread_mutex_t lock; // in my practical project, this variable is not global, but packed in a struct. here is for demo.
void init()
{
pthread_mutex_init(&lock, NULL); // the mutex is initialized as PTHREAD_MUTEX_NORMAL.
}
void EpollThread()
{
uint64_t unlocknum = 0;
......;
while (1)
{
......;
// I use a counter, and print some parameters of the mutex. The params are maintained by the kernel, I think.
pthread_mutex_unlock(&lock); // to notify ReadThread() that it can read data.
unlocknum++;
print(unlocknum);
print(lock.__data.__lock, lock.__data.__owner, lock.__data.__nusers);
......;
}
}
void ReadThread()
{
uint64_t locknum = 0;
......;
wait_lock:
pthread_mutex_lock(&lock);
locknum++;
print(locknum);
print(lock.__data.__lock, lock.__data.__owner, lock.__data.__nusers);
......; // read data and some other processes.
goto wait_lock;
}
In the practical test, I found the following odd things:
0. NOTE: the following questions are NOT IN ONE STACK.
1. After printing "_lock=0", it suddenly prints "_lock=2". I'm quite curious about this because there's only ONE thread calling pthread_mutex_lock().
2. A "__lock=0" is right after a pthread_mutex_lock(), and I know this according to 2 logs "locknum=xxx" & "__lock=0". Perhaps there's a pthread_mutex_unlock() between the above 2 logs?(the log subsystem is working in 2 threads)
3. An assert() occurs after a pthread_mutex_lock(). Through GDB, I can see, in the stack, the assert is in pthread_mutex_lock() "assert(__owner==0)". BUT, in the upper layer of THE stack where I call pthread_mutex_lock(), I get "lock._data._owner=0", that is, it cannot trigger the assert?!
If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall not be provided. Attempting to relock the mutex causes deadlock. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results.
I encountered an odd question about linux mutex lock, with Fedora 16 x64 as the development platform.
Code:
pthread_mutex_t lock; // in my practical project, this variable is not global, but packed in a struct. here is for demo.
void init()
{
pthread_mutex_init(&lock, NULL); // the mutex is initialized as PTHREAD_MUTEX_NORMAL.
}
void EpollThread()
{
uint64_t unlocknum = 0;
......;
while (1)
{
......;
// I use a counter, and print some parameters of the mutex. The params are maintained by the kernel, I think.
pthread_mutex_unlock(&lock); // to notify ReadThread() that it can read data.
unlocknum++;
print(unlocknum);
print(lock.__data.__lock, lock.__data.__owner, lock.__data.__nusers);
......;
}
}
void ReadThread()
{
uint64_t locknum = 0;
......;
wait_lock:
pthread_mutex_lock(&lock);
locknum++;
print(locknum);
print(lock.__data.__lock, lock.__data.__owner, lock.__data.__nusers);
......; // read data and some other processes.
goto wait_lock;
}
In the practical test, I found the following odd things:
0. NOTE: the following questions are NOT IN ONE STACK.
1. After printing "_lock=0", it suddenly prints "_lock=2". I'm quite curious about this because there's only ONE thread calling pthread_mutex_lock().
2. A "__lock=0" is right after a pthread_mutex_lock(), and I know this according to 2 logs "locknum=xxx" & "__lock=0". Perhaps there's a pthread_mutex_unlock() between the above 2 logs?(the log subsystem is working in 2 threads)
3. An assert() occurs after a pthread_mutex_lock(). Through GDB, I can see, in the stack, the assert is in pthread_mutex_lock() "assert(__owner==0)". BUT, in the upper layer of THE stack where I call pthread_mutex_lock(), I get "lock._data._owner=0", that is, it cannot trigger the assert?!
mutex lock and unlock must happen in a single thread. For your purpose you can use semaphores
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.