问题描述
我在与调用pthread_mutex_unlock一个问题，我的祖国活动NDK应用程序。我已经添加日志消息到每个互斥初始化，锁定，锁定的成功和解锁。我的程序是越来越陷入僵局，因为互斥解锁告诉我，该线程试图解锁互斥体并没有将其锁定。我的记录，否则说。所以我想知道如果有什么我做/不这样做可能会造成这一点。 （）中的数字是为mutex_t *后跟code线数目和线程通过pthread_self（）返回的标识。对我来说，它看起来好像线程1584064获取锁定，并做其处理。那么线程1597448试图锁定并正确暂停等待获取锁。问题是，当1584064然后完成其工作，并试图释放调用pthread_mutex_unlock返回错误（1）的锁。
I'm having an issue with pthread_mutex_unlock and my native activity NDK app. I've added logging messages to each mutex initialization, lock, lock success and unlock. My program is getting deadlocked because the mutex unlock is telling me that the thread trying to unlock the mutex did not lock it. My logging says otherwise. So I'm wondering if there is something I'm doing / not doing that could be causing this. The number in () is the mutex_t* followed by the code line number and thread id returned by pthread_self(). To me it looks as though thread 1584064 has acquired the lock and is doing its processing. Then thread 1597448 attempts to lock and correctly is paused waiting to acquire the lock. The problem is when 1584064 then completes its work and tries to release the lock pthread_mutex_unlock returns an error (1).
13 09-21：55：27.098：WARN /本地活动（1333年）：尝试锁定互斥
（2154220968）线：3041螺纹：1584064
13 09-21：55：27.098：WARN /本地活动（1333年）：成功：锁定互斥
（2154220968）线：3041螺纹：1584064
09-21 13:55:27.098: WARN/native-activity(1333): Success: Locked Mutex (2154220968) Line:3041 Thread:1584064
13 09-21：55：31.668：DEBUG / dalvikvm（352）：GC_EXPLICIT释放8K，4％免费
8606K / 8963K，暂停3毫秒+ 423ms
09-21 13:55:31.668: DEBUG/dalvikvm(352): GC_EXPLICIT freed 8K, 4% free 8606K/8963K, paused 3ms+423ms
13 09-21：55：31.898：WARN /本地活动（1333年）：尝试锁定互斥
（2154220968）线：3041螺纹：1597448
09-21 13:55:31.898: WARN/native-activity(1333): Try to lock mutex (2154220968) Line:3041 Thread:1597448
13 09-21：55：32.198：WARN /本地活动（1333年）：错误：1解锁
互斥（2154220968）线：3045螺纹：1584064
09-21 13:55:32.198: WARN/native-activity(1333): Error:1 Unlocking Mutex(2154220968) Line:3045 Thread:1584064
初始化是看起来像这样一个宏：
Initialization is a macro that looks like this:
#define InitializeCriticalSection(p, X) \
{ \
LOGW("Initialize Mutex(%u)", p); \
*p = PTHREAD_MUTEX_INITIALIZER; \
pthread_mutexattr_t attr; \
pthread_mutexattr_init(&attr); \
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); \
int ii_p = pthread_mutex_init((pthread_mutex_t *)p, &attr); \
pthread_mutexattr_destroy(&attr); \
LOGW("Initialize Mutex(%u) Returned %d", (pthread_mutex_t *)p, ii_p); \
}
一个线程是标准的NDK线，另一条是这样初始化我自己的计时器线程：
One thread is the standard NDK thread, the other one is my own timer thread initialized like this:
pthread_t thread;
pthread_attr_t pattr;
int state;
state = pthread_attr_init(&pattr);
pthread_attr_setdetachstate(&pattr, PTHREAD_CREATE_DETACHED);
if (!state)
{
LOGW("Creating Timers Thread %d MS", dwMsecs);
int iRetTest = pthread_create(&thread, &pattr, TimersThread, (void *)pTimer);
pthread_attr_destroy(&pattr);
}
等等错误处理
这似乎没有任何区别，如果我AttachCurrentThread在我的计时器线程虚拟机或没有。这似乎是互斥不能跨线程工作正常。预先感谢任何帮助，您可以提供。
It doesn't seem to make any difference if I AttachCurrentThread to the vm or not in my timers thread. It seems like mutexes are not working across threads correctly. THanks in advance for any help you can provide.
推荐答案
我想通了。问题是在初始化。虽然这与其他的几个平台，我真的没有这样做是正确的。如果使用自定义初始化，你应该新互斥）。新的init看起来是这样的：
I figured it out. The problem was in the initialization. Although this works on several other platforms, I really wasn't doing it right. If you use custom init you should new the mutex). New init looks like this:
#define InitializeCriticalSection(p) \
{ \
p = new pthread_mutex_t; \
LOGW("Initialize Mutex(%u)", p); \
pthread_mutexattr_t attr; \
pthread_mutexattr_init(&attr); \
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); \
int ii_p = pthread_mutex_init(p, &attr); \
pthread_mutexattr_destroy(&attr); \
LOGW("Initialize Mutex(%u) Returned %d", p, ii_p); \
}
哟！
这篇关于Android的NDK问题调用pthread_mutex_unlock问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！