Posix 信号量 =>如何在一段时间后关闭信号量。生产者-消费者问题

发布于 2024-10-31 07:32:19 字数 113 浏览 1 评论 0原文

我正在通过生产者读取文件,并由消费者将它们写入其他文件,当生产者读取输入文件时,我需要关闭其中一个信号量,并且消费者不再等待生产者将一些新输入插入到缓冲区。有什么办法可以做到这一点吗?

问候...

I am reading files by produces and writing them to the other files by consumers and when the input files are read by the producers I need to close one of the semaphore and consumers do not wait any more for producers for inserting some new input to buffer. Is there any way to do that?

Regards...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

属性 2024-11-07 07:32:19

几种可能性:

  • 使用一个标志来指示生产者已完成。解除对信号量的阻止的消费者需要检查该标志并在其设置时进行清理。当生产者设置标志时,它可以向信号量发出足够多的信号以释放任何可能的消费者。您需要小心处理竞争条件,其中某些内容排队等待消费,但在消费者通过检查该标志之前设置了“生产者完成”标志。如果您让消费者线程继续并尝试使工作项出列,但让它们干净地处理即使信号量已发出信号也无事可做的情况,那么这可能很容易处理。 然后让他们查看“生产者完成”标志。
  • 使用 pthread_kill() 向任何等待的消费者发送信号。这应该将它们踢出 sem_wait(),在那里它们可以检查 EINTR 返回代码。这也需要仔细编码以避免竞争。我对 POSIX 信号处理不是特别熟悉,但我确信它有自己的一套包袱,您需要非常小心才能正确处理。
  • 切换到使用带有互斥锁的条件变量,您可以在保留互斥锁的同时自动检查队列状态和完成条件。

当然,一旦完成,某人(生产者线程?)需要等待所有消费者线程清理 - 可能通过对它们执行 pthread_join() - 在信号量被销毁/关闭之前。

如果您已经使用信号量编码了某些内容,则条件变量选项可能是一个更大的变化,并且在生产和消费(也许)的正常情况下它可能不那么高效。但我敢打赌,推理可能的竞争条件并正确处理它们会更容易。请注意,我并不是说这很容易,只是说它可能会更容易。

A few possibilities:

  • use a flag that indicates the producer is done. Consumers who unblock from the semaphore need to check that flag and clean up when it's set. When the producer sets the flag, it can signal the semaphore enough times to release any possible consumers. You need to take care to deal with a race condition where something is queued for consumption, but the 'producer done' flag is set before a consumer gets past checking the flag. This can possibly be handled easily if you let the consumer threads go ahead and try to dequeue a work item, but have them cleanly handle a situation where there's nothing to do even though the semaphore was signaled. Then have them look at the 'producer done' flag.
  • use pthread_kill() to send a signal to any waiting consumers. This should kick them out of the sem_wait(), where they can check for the EINTR return code. This also would need to be coded carefully to avoid races. I'm not particularly familiar with POSIX signal handling, but I'm sure it comes with its own set of baggage that you need to be very careful in handling correctly.
  • switch to using condition variables with mutexes where you can check for the queue state and the done condition atomically while holding the mutex.

Of course, once that's been done someone (the producer thread?) needs to wait for all the consumer threads to clean up - probably by doing a pthread_join() on them - before the semaphore is destroyed/closed.

The condition variable option is probably a bigger change if you already have something coded up using semaphores, and it might not be as performant in the normal case when are being produced and consumed (maybe). But I'd bet that it's easier to reason about the possible race conditions and handle them correctly. Note that I don't say it's easy, just that it might be easier.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文