Recursos compartilhados, conflitos, acesso compartilhado - 1

"Oi, amigo! Quero falar sobre o compartilhamento de recursos. Em diferentes segmentos, naturalmente.

"Eu continuo falando sobre os problemas que acontecem ao trabalhar com vários threads e como resolvê-los. Isso não significa que usar threads seja ruim. Threads são uma ferramenta muito poderosa. Na verdade, eles permitem que você torne seu programa mais rápido e uniforme mais confiável. Quanto mais complexo é um programa, mais threads e várias partes independentes ele possui."

"Dividir um programa em partes independentes (livremente acopladas) é muito benéfico."

"Imagine que seu programa é dividido internamente em 100 threads. Mas você só tem um processador dual-core. Isso significa que em média 50 threads serão executadas em cada núcleo."

"Se você precisar aumentar o desempenho do programa, basta comprar um servidor de processador duplo e alguns processadores excelentes para ele. Isso pode levar até 32 núcleos, gerando um aumento de desempenho de 2 a 20 vezes. Dependendo do número de partes verdadeiramente independentes em que é dividido."

"Esta é uma das razões pelas quais o Java domina o desenvolvimento corporativo. Se uma empresa tem um programa interno complexo escrito por 20 desenvolvedores, é muito mais barato comprar outro servidor do que dobrar o desempenho do programa por meio da otimização."

"Então é disso que se trata."

"Mas! Toda vez que um desenvolvedor decide usar outro thread, ele resolve um problema e cria dois. Mais e mais threads não aumentarão indefinidamente o desempenho do programa."

"Primeiro, qualquer programa tem um trabalho que não pode ser dividido e executado em paralelo em diferentes threads. Segundo, todos os threads são executados no mesmo processador. Quanto mais threads você tiver, mais lento cada um funcionará."

"E, mais importante, os threads geralmente usam os mesmos objetos (geralmente chamados de 'recursos compartilhados')."

"Por exemplo, um encadeamento deseja salvar informações sobre o trabalho que concluiu em um arquivo. Se houver vários desses encadeamentos e eles desejarem gravar informações no mesmo arquivo, eles interferirão uns nos outros. Para evitar que o arquivo se torne um confusão confusa, o acesso ao arquivo é limitado, ou seja, enquanto um thread usa o arquivo, outros esperam."

"Sim, eu me lembro. Você faz isso usando a palavra-chave sincronizada ."

"Exatamente certo."

"E se os threads estiverem gravando em arquivos diferentes?"

"Formalmente, esses são objetos diferentes, mas provavelmente estão no mesmo disco rígido."

"Então, é realmente possível paralelizar algo dentro do processador?"

"Tecnicamente, sim, mas assim que seu thread precisar de algo além dos dados que possui, esse algo já pode estar ocupado por outro thread - e seu thread terá que esperar."

"Bem, o que devo fazer então? Como sei se devo fazer muitos fios ou não?"

"Isso é determinado diretamente pela arquitetura do seu programa. Todo projeto tem seu próprio 'arquiteto' que conhece todos os 'recursos' usados ​​no programa, conhece suas limitações e quão bem/mal eles são paralelizados."

"E se eu não souber?"

"Existem duas opções:"

a) trabalhar sob a supervisão de alguém que não

b) obter alguns caroços descobrindo por conta própria

"Sou um robô: não tenho caroços - apenas amassados."

"Bem, então, pegue alguns dentes."

"Entendo. Obrigado. Você esclareceu algumas coisas que eu já tinha começado a questionar."