bloqueio e não bloqueio
Assim como os significados literais blocking e non-blocking, podemos facilmente chegar à conclusão de que blocking significa que após chamar este método, a thread atual será bloqueada até que o método retorne, enquanto non-blocking é o contrário. o thread atual não será bloqueado e o resultado será retornado imediatamente , por exemplo, se nenhum dado for copiado para o buffer do kernel, mas o resultado precisar ser retornado imediatamente, a função read retornará -1 para informar o usuário que nenhum dado pode ser lido por esta chamada.
No entanto, esta conclusão não é rigorosa pelas seguintes razões:
Há três conceitos a serem observados aqui: hardware correspondente , buffer do kernel e buffer do usuário . Por exemplo, para a função de leitura, copiar dados do hardware correspondente para o buffer do kernel e copiar dados do buffer do kernel para o buffer do usuário requer a espera de ambas as etapas. Tanto o bloqueio quanto o não bloqueio são para a primeira etapa. Para a segunda etapa, seja bloqueio IO ou não bloqueio IO, o thread atual entrará no estado de bloqueio . Isso é muito importante e é a chave para distinguir não bloqueante e assíncrono posteriormente.
Pode-se ver acima que o bloqueio de IO bloqueador e não bloqueador se distingue principalmente da primeira etapa, que não é totalmente consistente com os conceitos de bloqueio e não bloqueio que entendemos.
síncrono e assíncrono
Sincronização significa que depois que a chamada é iniciada, ela não retornará até que o resultado seja retornado, enquanto assíncrona significa que o resultado é retornado imediatamente após o início da chamada. A partir desta perspectiva, IO sem bloqueio não pode ser considerada uma operação assíncrona .
Por que multiplexar IO é considerado sem bloqueio em vez de assíncrono
Sabemos que multiplexar IO é monitorar vários estados de soquete ao mesmo tempo. Por exemplo, quando há um soquete que pode ler dados, podemos chamar o método read para obter os dados, mas o readable aqui significa que há dados no buffer do kernel e ainda precisamos esperar que sejam copiados para o buffer do usuário quando chamamos read , então IO multiplexado não pode ser contado como assíncrono.
É altamente recomendável ler este artigo, que elabora o conceito de multiplexação IO: A multiplexação IO é assíncrona?
Operações relacionadas assíncronas
Muito foi dito acima, mas não há menção de operações relacionadas assíncronas. Na verdade, as operações assíncronas não são complicadas.Se o sistema operacional nos notificar quando copia completamente os dados para o buffer do usuário , isso equivale a obter assincronia. Com a ajuda da API relevante fornecida pelo sistema, podemos concluir esta operação e permitir que essas operações de IO sejam entregues ao sistema operacional para serem concluídas.
algumas digressões
A partir da discussão acima, não é difícil descobrir que, devido às operações de IO demoradas, sempre esperamos que o sistema operacional possa assumir total responsabilidade por essas operações. Afinal, cada chamada para a função read é uma chamada do sistema, e a chamada do sistema envolve a transferência do modo de usuário para o modo kernel. , há a sobrecarga da troca de contexto, portanto, esperamos que uma chamada do sistema possa concluir todas as operações relacionadas, de modo a evitar a necessidade de chamadas de sistema repetidas no futuro, o que vai desacelerar o programa.
link de referência
Como entender a diferença entre bloqueio sem bloqueio e assíncrono síncrono?