Que idéias falsas existem que afastam as pessoas do uso de threads? [fechadas]

Implementar o encadeamento em um programa é difícil, sim, no entanto, por que algumas pessoas não o implementam, mesmo quando há uma necessidade óbvia?

Um exemplo: o programa precisa carregar um conjunto de dados de um banco de dados, o que você deve fazer é fazer a conexão e obter os dados do banco de dados em um encadeamento de trabalho e carregá-lo na GUI, deixando o encadeamento da GUI responsivo para o usuário .

Mas não, conversei com pessoas que parecem pensar que os fios são maus e ruins e outros enfeites, e devemos evitá-los a todo custo. Eu até ouvi dizer que algum instrutor da classe desaconselhava o uso de threads e, portanto, não queria cobrir seu uso. O QUE???

Com o hardware entrando em vários núcleos, acho que precisamos entender melhor os threads e não ter medo de usá-los. Acho pessoalmente um assunto fascinante.

Então, quais são as coisas que você ouviu sobre a segmentação que são falsas?

Rosquear é difícil

Certo. Pode ser. No entanto, as pessoas têm essa ideia na cabeça que é tão difícil, de modo que não se incomodam em tentar descobrir.

Não é impossível.

Não é difícil a parte do encadeamento, mas a necessidade de sincronização e tudo o mais que vem com o uso de threads. No seu exemplo de GUI, como você informa o thread principal que o conjunto de dados está pronto para ser acessado? Você repassa um monte de retornos de chamada? Você espalha um monte de variáveis ​​de verificação por todo o seu código? Em alguns modelos de GUI, por exemplo, Silverlight, existe algo chamado afinidade de encadeamento, o que significa que você não pode acessar elementos da GUI localizados no encadeamento principal a partir de outros encadeamentos, portanto, é necessário sair do seu caminho para permitir que o encadeamento principal saiba que certas informações estão disponíveis. pronto para ser processado posteriormente.

Eu realmente não ouvi nenhuma coisa falsa sobre tópicos. Acabei de ler um monte de estudos de caso situacionais sobre a sincronização ser uma chatice quando qualquer algoritmo que você está usando não é inerentemente paralelo.

Rosqueamento resolve todos os seus problemas

Se você está tendo problemas de desempenho você deve não ir direto para threading.

As linhas são leves

Os segmentos são leves em dezenas e vinte anos. Gerar milhares de threads não é.

Rosquear é fácil [Java]

É fácil criar threads, isso não significa que você se beneficiará disso.

Você acabará perdendo quaisquer ganhos com o encadeamento, pois a correção de erros malucos que surgirão do uso de algumas bibliotecas / funções que não são seguras para threads (do que você não estava ciente) exigirá sincronização excessiva.

Você tem uma probabilidade muito maior de encontrar um bug que não poderá consertar se usar os threads quando não o fizer.

Para resumir em detalhes por que os threads são difíceis de usar: -
Coisas Verdadeiras 1) Precisa da sincronização e decisões cuidadosas sobre o que bloquear e quando bloquear
2) Nenhum controle sobre o fluxo do tempo de execução
3) Depuração difícil
4) (Muito poucas vezes) compatibilidade de plataforma: - Existem bibliotecas para cuidar disso

Coisas falsas: -
1) Conceitos confusos de funções seguras e re-entrantes de
tópicos 2) Os tópicos ficam bem no papel, mas são muito difíceis de implementar

Se você não quiser escrever testes para o seu código, não use threads.

Os threads não são para o programador típico de copiar e colar que não entende os fundamentos subjacentes do SO e da arquitetura do computador. Como 90% dos programadores estão familiarizados apenas com Java, essas realmente não são as pessoas que deveriam usar threads. Java torna os threads "fáceis", mas já vi muitos programadores que acham que, se usassem estruturas sincronizadas, seu código funcionaria em threads .... uhm não.

Dito isto, todo mundo precisa começar em algum lugar, apenas não faça seu primeiro projeto de encadeamento atualizando o servidor de back-end de produção da empresa.

Um exemplo: o programa precisa carregar um conjunto de dados de um banco de dados, o que você deve fazer é fazer a conexão e obter os dados do banco de dados em um encadeamento de trabalho e carregá-lo na GUI, deixando o encadeamento da GUI responsivo para o usuário .

Não vejo que essa situação represente a necessidade de usar a segmentação por pelo menos quatro razões:

1. A recuperação de dados deve ser muito rápida.

2. Em muitos aplicativos da Linha de negócios, o usuário não tem nada a ver com o aplicativo em um ou dois segundos em que está aguardando o resultado. Além disso, o usuário terá que esperar até que os dados retornem para concluir a tarefa desejada. A consulta, por outro lado, pode ser codificada de forma inteligente, de forma que recupere apenas uma página cheia de informações por vez e outras técnicas de otimização podem ajudar no tempo de resposta.

3. Nas interfaces baseadas na Web, os links podem ser ativados em relação ao modelo de segmentação.

4. A segmentação adiciona complexidade conforme você admite, alguns desenvolvedores abaixo da linha podem não conseguir adicionar recursos ou depurar códigos complexos.

Minha opinião é: use o encadeamento quando necessário, porque a manutenção e a confiabilidade do software são mais valiosas para uma organização do que a elegância do código.