- html - 出于某种原因,IE8 对我的 Sass 文件中继承的 html5 CSS 不友好?
- JMeter 在响应断言中使用 span 标签的问题
- html - 在 :hover and :active? 上具有不同效果的 CSS 动画
- html - 相对于居中的 html 内容固定的 CSS 重复背景?
当我在前任所有者死后尝试使用“trylock”锁定互斥锁时,我发现了意外行为
无需解锁。
第一个使用 'trylock' 的进程按预期获得 EOWNERDEAD 状态,因此使用 'unlock' 函数来释放互斥锁:
lock_status = pthread_mutex_trylock(mutex);
if (lock_status == EOWNERDEAD)
{
pthread_mutex_unlock(mutex);
printf("P1 mutex status: EOWNERDEAD\n");
}
else if (lock_status == ENOTRECOVERABLE)
{printf("P1 mutex status: ENOTRECOVERABLE\n");}
else if (lock_status == EBUSY)
{printf("P1 mutex status: EBUSY\n");}
else {printf("P1 mutex status: %d\n", lock_status);}
第二个执行相同的代码,如预期的那样获得 ENOTRECOVERABLE 状态。
else if (lock_status == ENOTRECOVERABLE)
{
pthread_mutex_destroy(mutex);
printf("P1 mutex status: ENOTRECOVERABLE\n");
}
但也许有比这种极端解决方案更好的方法,是吗?
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <pthread.h>
main(void)
{
int lock_status, mutex_fdesc;
pid_t process_id;
pthread_mutex_t* mutex;
pthread_mutexattr_t m_att;
//Process 1 die with locked mutex
process_id = fork();
if (process_id < 0) {exit(0);}
if (process_id == 0)
{
usleep(100000);
mutex_fdesc = shm_open("/mutex", O_RDWR, S_IRWXU | S_IRWXG);
mutex = (pthread_mutex_t*)mmap(NULL, sizeof(pthread_mutex_t),
PROT_READ | PROT_WRITE, MAP_SHARED, mutex_fdesc, 0);
close(mutex_fdesc);
pthread_mutex_lock(mutex);
exit(0);
}
///Process 2 try to lock mutex and gets EOWNERDEAD then make an unlock
process_id = fork();
if (process_id < 0) {exit(0);}
if (process_id == 0)
{
usleep(200000);
mutex_fdesc = shm_open("/mutex", O_RDWR, S_IRWXU | S_IRWXG);
mutex = (pthread_mutex_t*)mmap(NULL, sizeof(pthread_mutex_t),
PROT_READ | PROT_WRITE, MAP_SHARED, mutex_fdesc, 0);
close(mutex_fdesc);
lock_status = pthread_mutex_trylock(mutex);
if (lock_status == EOWNERDEAD)
{
pthread_mutex_unlock(mutex);
printf("P2 mutex status: EOWNERDEAD\n");}
else if (lock_status == ENOTRECOVERABLE)
{printf("P2 mutex status: ENOTRECOVERABLE\n");}
else if (lock_status == EBUSY)
{printf("P2 mutex status: EBUSY\n");}
else {printf("P2 mutex status: %d\n", lock_status);}
exit(0);
}
///Process 2 try to lock mutex and gets ENOTRECOVERABLE then do nothing
process_id = fork();
if (process_id < 0) {exit(0);}
if (process_id == 0)
{
usleep(400000);
mutex_fdesc = shm_open("/mutex", O_RDWR, S_IRWXU | S_IRWXG);
mutex = (pthread_mutex_t*)mmap(NULL, sizeof(pthread_mutex_t),
PROT_READ | PROT_WRITE, MAP_SHARED, mutex_fdesc, 0);
close(mutex_fdesc);
lock_status = pthread_mutex_trylock(mutex);
if (lock_status == EOWNERDEAD)
{
pthread_mutex_unlock(mutex);
printf("P3 mutex status: EOWNERDEAD\n");}
else if (lock_status == ENOTRECOVERABLE)
{printf("P3 mutex status: ENOTRECOVERABLE\n");}
else if (lock_status == EBUSY)
{printf("P3 mutex status: EBUSY\n");}
else {printf("P3 mutex status: %d\n", lock_status);}
exit(0);
}
mutex_fdesc = shm_open("/mutex", O_RDWR | O_CREAT | O_EXCL, S_IRWXU | S_IRWXG);
ftruncate(mutex_fdesc, sizeof(pthread_mutex_t));
mutex = (pthread_mutex_t*)mmap(NULL, sizeof(pthread_mutex_t),
PROT_READ | PROT_WRITE, MAP_SHARED, mutex_fdesc, 0);
close(mutex_fdesc);
pthread_mutexattr_init(&m_att);
pthread_mutexattr_setpshared(&m_att, PTHREAD_PROCESS_SHARED);
pthread_mutexattr_setrobust(&m_att, PTHREAD_MUTEX_ROBUST);
pthread_mutex_init(mutex, &m_att);
pthread_mutexattr_destroy(&m_att);
///Parent process try to lock the mutex and gets EBUSY
usleep(800000);
lock_status = pthread_mutex_trylock(mutex);
if (lock_status == EOWNERDEAD)
{printf("Pparent mutex status: EOWNERDEAD\n");}
else if (lock_status == ENOTRECOVERABLE)
{printf("Pparent mutex status: ENOTRECOVERABLE\n");}
else if (lock_status == EBUSY)
{printf("Pparent mutex status: EBUSY\n");}
else {printf("Pparent mutex status: %d\n", lock_status);}
pthread_mutex_destroy(mutex);
munmap((void*)mutex, sizeof(pthread_mutex_t));
shm_unlink("/mutex");
wait(NULL);
wait(NULL);
wait(NULL);
exit(0);
}
最佳答案
我认为您所看到的是,当它返回 EOWNERDEAD
时,锁定互斥锁的尝试被认为是成功的。 (这是恢复语义所必需的,以便只有一个线程尝试恢复)以及当它返回 ENOTRECOVERABLE
时也是如此。 ,我同意这是令人惊讶的,并且似乎与文档相反。文档说,如果线程接收 EOWNERDEAD
在解锁之前不会使互斥锁保持一致,然后所有后续尝试锁定它都将返回 ENOTRECOVERABLE
.我在文档中没有看到任何内容表明这不应该适用于 pthread_mutex_trylock()
与 pthread_mutex_lock()
相同.
如果您想将其报告为错误,那么您可以针对提供 pthreads 实现的任何库报告它。这至少会因操作系统而异。
in my purpouse i have to check the mutex status before doing any operation, so i cannot use the 'lock' function or a deadlock may occur.
EOWNERDEAD
或
ENOTRECOVERABLE
首先。
pthread_mutex_trylock()
可能是矫枉过正,如果不是根本不合适的话。如果在无法锁定互斥锁的情况下可以做有用的工作,则可以使用它。也许在你的情况下有,但那将是不寻常的。例如,如果您只是在再次尝试之前延迟,那么您最好只使用
pthread_mutex_lock()
首先。
关于c - 在 EOWNERDEAD 状态互斥锁上的 Trylock,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66307312/
以下代码已被 Fortify 标记为违规(锁的“未释放资源”) try { if (lock.tryLock(1, TimeUnit.SECONDS)) { try { //d
我正在实现 ShareKit,到目前为止在 iOS5.1 和 6.0 上运行良好,但是 5.0 在模拟器中给我带来了一些问题。 每当我执行操作表并离开程序(例如在浏览器中启动 Facebook)时,我
我想知道是否有人可以帮助我。我是并发编程的新手,我有以下代码,有时会给我一个 IllegalMonitorStateException 作为当前不拥有锁的线程正在尝试解锁。 我在 OTN 论坛上被告知
我遇到了以下问题: 我们有一个包含两个步骤(s1 和s2)的多部分流程P。该过程已实现,在 s1 中获取了一个锁 - 但未释放。在 s2 中再次需要锁(?)并且在 s2 完成后,再次释放锁。 来自do
tryLock方法的文档说它是一个非阻塞方法 这允许您获得/获取锁(如果在调用该方法时可能的话)。 但我想知道:如何才能在获得锁的同时保证 你的方法 (tryLock) 是非阻塞的?!获得锁意味着你是
我尝试了使用同步、lock.lock()和lock.tryLock()的线程竞赛程序,我发现使用同步和lock.lock()工作得很好,但lock.tryLock()本身不是线程安全的。此方法无法获取
这是关于可重入锁中的 tryLock() 方法。我正在运行下面的示例代码。我知道这段代码会陷入死锁。 import java.util.concurrent.locks.ReentrantLock;
我有一个线程服务器,可以添加/附加/读取文件并将数据中继到客户端。 如果正在添加一个文件,则没有其他线程可以追加/读取它。如果正在追加文件,则没有线程可以追加/读取它。如果正在读取文件,则没有其他线程
在 API docs方法tryLock()的Lock接口(interface),粘贴此代码示例, A typical usage idiom for this method would be: L
我想我只是没有看到一些东西,因为我过去已经让它工作了。 我的锁没有持有独占锁,当创建对象的新实例时,tryLock 返回 true 并安排另一个 TimerTask。 public class A {
我有两个进程可能同时访问同一个文件,想实现文件锁定。问题似乎是一个进程是用 java 编写的,另一个是用 C 编写的,并且不清楚在 java 端如何实现低级锁定。该平台是 Solaris 10。我试图
我正在使用 D3DImage 作为我的 WPF 用户控件的一部分。极少数情况下,在渲染时,D3DImage.TryLock 会失败。 到目前为止,我还没有找到任何关于 D3D.TryLock 为什么会
快速背景: app是一个音频播放器,ffmpeg编译为native共享对象用于解码,单独的native library编译为共享对象用于音频处理,AudioTrack用于输出处理后的音频。所有音频功能
在 Qt 文档中关于 QMutex据说: (...) When you call lock() in a thread, other threads that try to call lock() i
当我在前任所有者死后尝试使用“trylock”锁定互斥锁时,我发现了意外行为 无需解锁。 第一个使用 'trylock' 的进程按预期获得 EOWNERDEAD 状态,因此使用 'unlock' 函数
我编写了一个小方法,用于告诉我应用程序的另一个实例是否已在运行。我知道有很多方法可以查明另一个实例是否正在运行,但我选择了这个。我正在创建一个空文件并在应用程序实例期间保持锁定状态。如果另一个实例正在
对 trylock 的不当使用 T1 T2 x = 42; while (
这个问题已经有答案了: 已关闭10 年前。 Possible Duplicate: Problem with Java file locking mechanism (FileLock etc) 在下
如果我手动打开 .txt 文件,然后执行代码来检查文件是否打开。总是说文件未打开。但相同的代码对于任何 MS Office(.doc、.xls、.ppt)都可以按预期工作。 这是代码片段:
ReentrantReadWriteLock.ReadLock ReentrantReadWriteLock.WriteLock 对于上面的两个类,我是这样调用锁的吗 try { readL
我是一名优秀的程序员,十分优秀!