Dan*_*udy 4 c multithreading freebsd pthreads
考虑以下测试程序:
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <strings.h>
#include <unistd.h>
#include <signal.h>
#include <pthread.h>
pthread_mutex_t mutex;
pthread_mutexattr_t mattr;
pthread_t thread1;
pthread_t thread2;
pthread_t thread3;
void mutex_force_unlock(pthread_mutex_t *mutex, pthread_mutexattr_t *mattr)
{
int e;
e = pthread_mutex_destroy(mutex);
printf("mfu: %s\n", strerror(e));
e = pthread_mutex_init(mutex, mattr);
printf("mfu: %s\n", strerror(e));
}
void *thread(void *d)
{
int e;
e = pthread_mutex_trylock(&mutex);
if (e != 0)
{
printf("thr: %s\n", strerror(e));
mutex_force_unlock(&mutex, &mattr);
e = pthread_mutex_unlock(&mutex);
printf("thr: %s\n", strerror(e));
if (e != 0) pthread_exit(NULL);
e = pthread_mutex_lock(&mutex);
printf("thr: %s\n", strerror(e));
}
pthread_exit(NULL);
}
void * thread_deadtest(void *d)
{
int e;
e = pthread_mutex_lock(&mutex);
printf("thr2: %s\n", strerror(e));
e = pthread_mutex_lock(&mutex);
printf("thr2: %s\n", strerror(e));
pthread_exit(NULL);
}
int main(void)
{
/* Setup */
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, PTHREAD_MUTEX_ERRORCHECK);
//pthread_mutexattr_settype(&mattr, PTHREAD_MUTEX_NORMAL);
pthread_mutex_init(&mutex, &mattr);
/* Test */
pthread_create(&thread1, NULL, &thread, NULL);
pthread_join(thread1, NULL);
if (pthread_kill(thread1, 0) != 0) printf("Thread 1 has died.\n");
pthread_create(&thread2, NULL, &thread, NULL);
pthread_join(thread2, NULL);
pthread_create(&thread3, NULL, &thread_deadtest, NULL);
pthread_join(thread3, NULL);
return(0);
}
Run Code Online (Sandbox Code Playgroud)
现在,当这个程序运行时,我得到以下输出:
Thread 1 has died.
thr: Device busy
mfu: Device busy
mfu: No error: 0
thr: Operation not permitted
thr2: No error: 0
thr2: Resource deadlock avoided
Run Code Online (Sandbox Code Playgroud)
现在我知道之前已经多次询问过了,但有没有办法强行解锁互斥锁?似乎实现只允许锁定它的线程解锁,因为它似乎主动检查,即使使用正常的互斥锁类型.
我为什么要这样做?它与编码防弹网络服务器有关,该服务器能够从大多数错误中恢复,包括线程意外终止的错误.此时,我看不到从与锁定它的线程不同的线程解锁互斥锁的方法.所以我看到它的方式是我有几个选择:
我之前已经问过这个问题但是,绝对想要这个功能的能力并没有得到答案(我已经尝试过了),所以我有点坚持这个.我没有这样设计,我真的想拍摄那个做过的人,但这也不是一个选择.
在有人说什么之前,我对pthread_kill的使用在POSIX下是合法的......我查了一下.
我忘了提一下,这是我们正在使用的FreeBSD 9.3.
使用强大的互斥锁,如果锁定线程死亡,请使用pthread_mutex_consistent()修复互斥锁.
如果互斥锁是处于不一致状态的强健互斥锁,则pthread_mutex_consistent()函数可用于将由互斥锁引用的互斥锁保护的状态再次标记为一致.
如果强健互斥锁的所有者在持有互斥锁时终止,则互斥锁变得不一致,并且获取互斥锁的下一个线程将通过返回值[EOWNERDEAD]通知状态.在这种情况下,在状态标记为一致之前,互斥锁不会再次正常使用.
如果获取带有返回值[EOWNERDEAD]的互斥锁的线程在调用pthread_mutex_consistent()或pthread_mutex_unlock()之前终止,则获取互斥锁的下一个线程将通过返回值[EOWNERDEAD]通知互斥锁的状态. ].
我想出了一个可行的方法来处理这种情况。正如我之前提到的,FreeBSD 不支持强大的互斥体,因此该选项已被排除。另外,如果线程锁定了互斥体,则无法通过任何方式将其解锁。
因此,我为解决该问题所做的就是放弃互斥体并将其指针放在列表上。由于锁包装器代码使用 pthread_mutex_trylock,然后在失败时放弃 CPU,因此任何线程都不会陷入等待永久锁定互斥锁的状态。在健壮互斥体的情况下,锁定互斥体的线程如果获得 EOWNERDEAD 作为返回码,将能够恢复它。
以下是定义的一些内容:
/* Checks to see if we have access to robust mutexes. */
#ifndef PTHREAD_MUTEX_ROBUST
#define TSRA__ALTERNATE
#define TSRA_MAX_MUTEXABANDON TSRA_MAX_MUTEX * 4
#endif
/* Mutex: Mutex Data Table Datatype */
typedef struct mutex_lock_table_tag__ mutexlock_t;
struct mutex_lock_table_tag__
{
pthread_mutex_t *mutex; /* PThread Mutex */
tsra_daclbk audcallbk; /* Audit Callback Function Pointer */
tsra_daclbk reicallbk; /* Reinit Callback Function Pointer */
int acbkstat; /* Audit Callback Status */
int rcbkstat; /* Reinit Callback Status */
pthread_t owner; /* Owner TID */
#ifdef TSRA__OVERRIDE
tsra_clnup_t *cleanup; /* PThread Cleanup */
#endif
};
/* ******** ******** Global Variables */
pthread_rwlock_t tab_lock; /* RW lock for mutex table */
pthread_mutexattr_t mtx_attrib; /* Mutex attributes */
mutexlock_t *mutex_table; /* Mutex Table */
int tabsizeentry; /* Table Size (Entries) */
int tabsizebyte; /* Table Size (Bytes) */
int initialized = 0; /* Modules Initialized 0=no, 1=yes */
#ifdef TSRA__ALTERNATE
pthread_mutex_t *mutex_abandon[TSRA_MAX_MUTEXABANDON];
pthread_mutex_t mtx_abandon; /* Abandoned Mutex Lock */
int mtx_abandon_count; /* Abandoned Mutex Count */
int mtx_abandon_init = 0; /* Initialization Flag */
#endif
pthread_mutex_t mtx_recover; /* Mutex Recovery Lock */
Run Code Online (Sandbox Code Playgroud)
这是锁恢复的一些代码:
/* Attempts to recover a broken mutex. */
int tsra_mutex_recover(int lockid, pthread_t tid)
{
int result;
/* Check Prerequisites */
if (initialized == 0) return(EDOOFUS);
if (lockid < 0 || lockid >= tabsizeentry) return(EINVAL);
/* Check Mutex Owner */
result = pthread_equal(tid, mutex_table[lockid].owner);
if (result != 0) return(0);
/* Lock Recovery Mutex */
result = pthread_mutex_lock(&mtx_recover);
if (result != 0) return(result);
/* Check Mutex Owner, Again */
result = pthread_equal(tid, mutex_table[lockid].owner);
if (result != 0)
{
pthread_mutex_unlock(&mtx_recover);
return(0);
}
/* Unless the system supports robust mutexes, there is
really no way to recover a mutex that is being held
by a thread that has terminated. At least in FreeBSD,
trying to destory a mutex that is held will result
in EBUSY. Trying to overwrite a held mutex results
in a memory fault and core dump. The only way to
recover is to abandon the mutex and create a new one. */
#ifdef TSRA__ALTERNATE /* Abandon Mutex */
pthread_mutex_t *ptr;
/* Too many abandoned mutexes? */
if (mtx_abandon_count >= TSRA_MAX_MUTEXABANDON)
{
result = TSRA_PROGRAM_ABORT;
goto error_1;
}
/* Get a read lock on the mutex table. */
result = pthread_rwlock_rdlock(&tab_lock);
if (result != 0) goto error_1;
/* Perform associated data audit. */
if (mutex_table[lockid].acbkstat != 0)
{
result = mutex_table[lockid].audcallbk();
if (result != 0)
{
result = TSRA_PROGRAM_ABORT;
goto error_2;
}
}
/* Allocate New Mutex */
ptr = malloc(sizeof(pthread_mutex_t));
if (ptr == NULL)
{
result = errno;
goto error_2;
}
/* Init new mutex and abandon the old one. */
result = pthread_mutex_init(ptr, &mtx_attrib);
if (result != 0) goto error_3;
mutex_abandon[mtx_abandon_count] = mutex_table[lockid].mutex;
mutex_abandon[mtx_abandon_count] = mutex_table[lockid].mutex;
mtx_abandon_count++;
mutex_table[lockid].mutex = ptr;
#else /* Recover Mutex */
/* Try locking the mutex and see what we get. */
result = pthread_mutex_trylock(mutex_table[lockid].mutex);
switch (result)
{
case 0: /* No error, unlock and return */
pthread_unlock_mutex(mutex_table[lockid].mutex);
return(0);
break;
case EBUSY: /* No error, return */
return(0);
break;
case EOWNERDEAD: /* Error, try to recover mutex. */
if (mutex_table[lockid].acbkstat != 0)
{
result = mutex_table[lockid].audcallbk();
if (result != 0)
{
if (mutex_table[lockid].rcbkstat != 0)
{
result = mutex_table[lockid].reicallbk();
if (result != 0)
{
result = TSRA_PROGRAM_ABORT;
goto error_2;
}
}
else
{
result = TSRA_PROGRAM_ABORT;
goto error_2;
}
}
}
else
{
result = TSRA_PROGRAM_ABORT;
goto error_2;
}
break;
case EDEADLK: /* Error, deadlock avoided, abort */
case ENOTRECOVERABLE: /* Error, recovery failed, abort */
/* NOTE: We shouldn't get this, but if we do... */
abort();
break;
default:
/* Ambiguous situation, best to abort. */
abort();
break;
}
pthread_mutex_consistant(mutex_table[lockid].mutex);
pthread_mutex_unlock(mutex_table[lockid].mutex);
#endif
/* Housekeeping */
mutex_table[lockid].owner = pthread_self();
pthread_mutex_unlock(&mtx_recover);
/* Return */
return(0);
/* We only get here on errors. */
#ifdef TSRA__ALTERNATE
error_3:
free(ptr);
error_2:
pthread_rwlock_unlock(&tab_lock);
#else
error_2:
pthread_mutex_unlock(mutex_table[lockid].mutex);
#endif
error_1:
pthread_mutex_unlock(&mtx_recover);
return(result);
}
Run Code Online (Sandbox Code Playgroud)
因为 FreeBSD 和 Linux 一样是一个不断发展的操作系统,所以我已经做出了规定,允许将来使用强大的互斥体。由于没有健壮的互斥体,实际上没有办法进行增强的错误检查,而如果支持健壮的互斥体,则可以使用增强的错误检查。
对于稳健的互斥体,执行增强的错误检查以验证恢复互斥体的需要。对于不支持健壮互斥体的系统,我们必须信任调用者来验证有问题的互斥体是否需要恢复。此外,还进行了一些检查以确保只有一个线程执行恢复。阻塞在互斥体上的所有其他线程都将被阻塞。我已经考虑过如何向其他线程发出恢复正在进行中的信号,因此例程的这方面仍然需要工作。在恢复情况下,我正在考虑比较指针值以查看互斥体是否被替换。
在这两种情况下,审计例程都可以设置为回调函数。审计例程的目的是验证并纠正受保护数据中的任何数据差异。如果审核未能更正数据,则调用另一个回调例程,即数据重新初始化例程。这样做的目的是重新初始化受互斥体保护的数据。如果失败,则调用 abort() 来终止程序执行并删除核心文件以进行调试。
对于废弃互斥锁的情况,指针不会被丢弃,而是被放置在一个列表上。如果放弃太多互斥体,则程序将中止。如上所述,在互斥锁例程中,使用 pthread_mutex_trylock 代替 pthread_mutex_lock。这样,任何线程都不会被死互斥体永久阻塞。因此,一旦互斥表中的指针切换为指向新的互斥体,所有在该互斥体上等待的线程将立即切换到新的互斥体。
我确信这段代码中存在错误/错误,但这是一项正在进行的工作。虽然还没有完全完成和调试,但我觉得这里已经足够回答这个问题了。