信号/暂停死锁
Signal/Pause Deadlock
我很难通过信号和共享内存来管理子进程(我知道管道本可以更好)。我有以下循环:
* parent processing something, then signaling the children and going into pause,
* children processing something, then signaling the parent and going into pause,
* etc. etc.
问题是,在向父母发出信号(通过kill)后的某个时候,操作系统会切换到父母,而从不让孩子进入pause()。当它恢复子级时(在父级调用暂停之后),子级暂停,我出现死锁:(.
有什么建议吗?
为了避免这种竞争,您需要屏蔽与sigprocmask()
一起使用的信号。然后,代替pause()
,使用sigsuspend()
原子性地解除信号阻塞并挂起进程。
这意味着,如果在进程调用sigsuspend()
之前发送信号,则直到sigsuspend()
才会发送信号。
您正试图使用信号机制自行实现原子信号量,但正如您所发现的,这是不可能的,因为您没有得到使其工作所需的保证。
我建议研究pthreads系统提供的设施,从多进程范式转向多线程范式。如果做不到这一点,您可能会尝试使用(严重老化的)System V IPC机制,但我认为使用pthreads会更好。
相关文章:
- 获取日期异步信号安全吗?如果在信号处理程序中使用,它会导致死锁吗
- 如何在没有死锁和/或争用的情况下正确使用 std::mutex C++?
- 用C++中的std::condition_variable将线程置于死锁中会有风险吗
- 使用 std::async 时死锁,将来作为成员
- 如何调试读写器锁的死锁?
- 为什么在Visual Studio 2013上的std::this_thread::sleep_for上死锁
- localtime() 函数正在调用 ___lll_lock_wait_private(),这会使线程陷入死锁
- 如何重现 Boost 进程文档提示的死锁?
- 多线程Windows GUI应用程序中的死锁
- 为什么printf会导致与future.get的死锁,而cout则不会?
- C++中具有阻塞队列和障碍的死锁
- 死锁使用 std::mutex 来保护多个线程中的 cout
- 避免并发等待对象中的死锁
- 在VC++中从DLLMAIN内部调用D3D的CREATEDEVICE时,它会创建一个死锁(loaderlock?)。有没有办法克服这个问题?最终目标内
- 当用2个螺纹锁定时,将recursive_mutex死锁
- 程序在 C++11 中使用条件变量进入死锁
- 一个线程提升的死锁
- 单个生产者/多个消费者死锁
- 当被调用方法使用调用方已锁定的同一锁时,如何避免死锁
- 信号/暂停死锁