Concorrência, paralelismo, assincronia, non-blocking e seus conceitos

Comecei com uma breve organização dos termos e cobri uma ampla gama de tópicos, de gráficos a semicondutores.

1. Termos
   • concorrência / paralelismo
   • assíncrono / non-blocking
   • preemptivo / não preemptivo
2. Sistema operacional e processador
   • sistema operacional
   • processador
3. Corrotinas e fibers
   • fiber
   • corrotina
4. Generators, Async/Await e continuations
   • generator
   • Async / Await
   • continuation
5. Promise e Future
6. Multiplexação de I/O
   • multiplexação
   • socket
   • modelos de I/O
7. Ring buffer, modelos modernos de I/O, LMAX Disruptor
   • ring buffer
   • modelos modernos de I/O
   • LMAX Disruptor
8. Primitivas de sincronização
   • necessidade
   • thread safety
   • spinlock
   • mutex
   • semáforo
   • STM
   • GIL
9. Abordagens de outras linguagens de script e os padrões Reactor/Proactor
   • Ractor (Ruby)
   • Node.js (padrão Reactor)
   • padrão Proactor
10. CSP e atores
    • CSP
    • atores
11. Green threads, goroutines e tecnologias modernas de runtime assíncrono
    • green threads
    • runtimes modernos de CSP
    • runtimes modernos de atores
12. Paralelismo
    • SIMD e pipelining
    • OpenMP & MPI
    • técnicas modernas de paralelismo
    • arquitetura lambda
13. GPU
    • pipeline e shaders
    • monitor
    • buffering
    • sincronização vertical
    • frame pacing e beam racing
    • compositor
    • APIs / bibliotecas gráficas
14. Outros chips
    • visão geral
    • DSP
    • FPGA
    • TPU
15. Referências

[roxie]

Em síncrono e assíncrono, quem verifica a conclusão do trabalho?
Em blocking e non-blocking, existe controle de execução?

Vejo essa frase sendo repetida exatamente da mesma forma em inúmeros blogs, e fiquei curioso sobre qual é a fonte original.

A maioria dos blogs está ocupada demais referenciando uns aos outros, então não consegui inferir o texto original; o máximo que encontrei foi o documento sobre AIO da IBM, mas me parece que ali a discussão fica limitada apenas a kernel I/O. E também ouvi dizer que esse próprio critério de distinção é controverso.

Isso é um critério de julgamento confiável?

[alstjr7375]

Primeiro, acho que dá para basear síncrono/assíncrono na área de circuitos.
Circuitos síncronos usam clock para temporização, e os assíncronos são acionados por eventos ou outras entradas.
Ou seja, não parece forçado definir uma API assíncrona da mesma forma, como algo acionado por callbacks etc.
https://developer.mozilla.org/en-US/docs/…

No caso de APIs bloqueantes/não bloqueantes, uma definição adequada é se é necessário esperar obrigatoriamente pela operação ou não.
No entanto, para não esperar, é preciso haver uma implementação em que a função chamada tenha o controle, então acho que existe uma tendência de explicar bastante por esse lado.
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Eu tinha omitido isso para passar rapidamente, mas vou tentar acrescentar esse conteúdo também.

[roxie]

Concordo com tudo o que você disse. No entanto, ainda acho difícil ter certeza se esses dois eixos de referência devem ser desenhados em uma seção em forma de quadrante, se isso é possível, e se eles podem ser distinguidos adequadamente dessa forma. Para mim, Blocking e Sync parecem compartilhar conceitualmente 90% do mesmo contexto. O mesmo vale para Non-Blocking e Async.

[alstjr7375]

Embora Blocking-Sync e Non-Blocking-Async sejam frequentemente usados juntos, há casos em que é necessário diferenciá-los.

• Blocking-Async: multiplexação de I/O, como select
• Non-Blocking-Sync: polling de dados

Por isso, eu penso que, na verdade, o correto é usá-los de forma distinta.

[roxie]

Parece que eu quase não entendo os exemplos que você mencionou, então acho que fica mais difícil me identificar com o ponto.

https://incredible-larva.tistory.com/entry/IO-Multiplexing-Topabogi-1bu neste texto, a explicação é a seguinte:

No fim das contas, o user process que fez a chamada de select olha o valor retornado para decidir se há trabalho subsequente a fazer. Como várias requisições de I/O que chegam de forma imprevisível são gerenciadas ao mesmo tempo, às vezes isso é visto como algo assíncrono, mas, no fim, cada operação individual de I/O propriamente dita apresenta um comportamento síncrono.

Queria saber qual é a sua opinião sobre isso. Na verdade, a partir desse ponto, passei a sentir que essa classificação 2x2 já não faz mais muito sentido. Parece que as interpretações variam bastante dependendo do domínio e da perspectiva.

[alstjr7375]

Em seguida, ao esperar pela resposta do kernel, chega um sinal de callback do kernel informando que o valor de resultado está pronto, e o processo do usuário então copia os dados para o seu próprio buffer.

Como essa parte é um método acionado por callback, como vocês concordaram acima, se for preciso realmente distinguir/definir, acho que o mais correto seria chamar isso de Blocking-Async.
Acredito que pode haver casos em que, dependendo da perspectiva, isso pareça ambíguo.

No entanto, polling é um exemplo claro:
https://en.wikipedia.org/wiki/Polling_(computer_science)

No caso de polling, como se verifica repetidamente se os dados estão prontos, é um exemplo apropriado de Sync-Blocking.

[wonkwh]

Uau, obrigado pelo ótimo material.

[kayws426]

Li com gosto!

[bus710]

A rolagem parece não ter fim mesmo, nossa.
Acho que o livro "7 Modelos de Concorrência", que trata de um tema parecido, parece valer a leitura pelo menos uma vez.

[alstjr7375]

Comparando os sumários, parecem bem parecidos.
Parece ser um bom livro