Início / coding / Perguntas / 79234872
Accepted
albert
Asked: 2024-11-29 01:35:59 +0800 CST

construções de sincronização padrão - lógica por trás de wait() e try_wait_for()

  • 772

Quero esperar uma vez pelos resultados de vários outros threads. A std::latchseria uma construção adequada - a de espera usa wait()o produtor count_down(), mas quero poder definir um tempo limite, então preciso da funcionalidade wait_for . Infelizmente std::latchnão tem wait_for . Bem std::semaphore, tem, mas geralmente std::semaphoreé usado em lógica inversa. Seria adequado se eu pudesse usar um valor de inicialização negativo, mas mesmo que seja um tipo assinado ( ptrdiff_t) não é permitido - pré-condição: desejado >= 0. std::atomic wait()- poderia resolver todas as tarefas de sincronização, mas... sem wait_for . Parece que preciso construir meu próprio latch com std::condition_variable e std::mutex.

Mas eu gostaria de entender por que algumas construções oferecem funcionalidade de tempo limite (semáforo, mutex, condicional) e outras (trava, barreira, espera atômica) não - há uma razão ou é só porque sim?

Editar Parece que não sou o único que gosta de ter operações temporizadas em atomics: APIs de espera temporizada (try_wait, wait_for e wait_until) para std::atomic são propostas em P2643, visando C++26. ( stack overflow / C++20: Como esperar por um objeto atômico com tempo limite?

O uso interprocessual (memória compartilhada) de atomic-wait seria um sonho real ;-)

c++

1 respostas

  1. Best Answer

    O motivo pelo qual std::latche std::barriernão incluem um wait_formétodo se resume principalmente ao seu design e propósito. Essas ferramentas são destinadas a manter a sincronização de threads simples. A std::latché apenas um ponto de verificação único, e a std::barrierfunciona em várias fases. Adicionar timeouts os tornaria mais complicados, o que vai contra seu design mínimo e direto.

    Diferentemente de coisas como std::condition_variableou std::semaphore, que dependem de certas condições sendo atendidas (e podem nunca acontecer), std::latche std::barriersão mais baseadas em estado. Elas assumem que todas as threads eventualmente chegarão, então há menos necessidade de timeouts. Se você pensar sobre isso, timeouts são super úteis para evitar coisas como deadlocks, mas com essas construções, é meio que assumido que você já está gerenciando as threads corretamente para evitar esse problema.

    Se você precisar de algo como um latch, mas com um timeout, você pode construir um você mesmo usando ferramentas como std::mutexe std::condition_variable. Por exemplo, você pode escrever uma TimedLatchclasse simples que permite que você espere por um número definido de threads, mas também desista se demorar muito. É um pouco de trabalho extra, mas lhe dá flexibilidade extra quando você precisa.

    • 0

relate perguntas