O multitarefa deve ser usado para tarefas que não envolvem a operação IO?

5

Eu estava lendo um livro sobre OS e fiquei confuso entre diferentes terminologias. Espero ter minha dúvida esclarecida aqui. Essas perguntas podem ser muito básicas para alguns especialistas, mas acho essa plataforma mais adequada para tais esclarecimentos.

Os processos são executados pela CPU e toda essa operação é gerenciada pelo sistema operacional. Para CPU de núcleo único, a qualquer momento, apenas um processo será executado. A CPU salva o estado de um processo para processar bloco de controle e inicia a execução de outro processo que estava aguardando e essa comutação é tão rápida que parece que todos os processos estão sendo executados simultaneamente.

A necessidade de threads diferentes em um processo foi sentida para obter um controle mais refinado sobre o processo, o que significa que, se o processo estiver aguardando devido a alguma operação de E / S vinculada, mesmo que esse processo seja selecionado pela CPU, ele não fará qualquer coisa.

Portanto, se vários encadeamentos estiverem sendo executados em um processo, se um encadeamento cuidar da atividade de E / S, outros encadeamentos poderão fazer alguma computação real, desde que esse processo seja selecionado pela CPU.

Aqui estão minhas perguntas: O multithreading é efetivo apenas se a tarefa envolver a atividade de E / S? Por que o Multi-threading é preferível ao multiprocessamento? (é porque os threads irão compartilhar o mesmo espaço de memória?)

Por que processadores multi-core são melhores para multi-threading? (Eu acho que eles serão melhores mesmo se você não usar multi-threading, por que tão excitante em nome do multi-threading?). E, de qualquer maneira, threads em diferentes processos não compartilharão a mesma memória, portanto, dois threads em execução em diferentes processos em diferentes núcleos são como executar diferentes processos. É apenas que eles serão paralelos e o paralelo real, não o pseudo-paralelo.

    
por AKS 02.08.2013 / 18:39
fonte

4 respostas

3

Uma das principais razões para o uso de threads, mesmo em um processo totalmente limitado pela CPU, é permitir a interação ou atualizar a saída do progresso por meio de uma interface do usuário de algum tipo. Embora a execução do cálculo em primeiro plano, sem permitir a interação, seja mais eficiente, o menor custo de troca de tarefas e de manipulação de eventos da interface do usuário geralmente supera a penalidade de forçar um usuário a esperar indefinidamente por um processo.

Outro caso em que executar vários encadeamentos em um único núcleo seria mais eficiente é quando um processo de vários estágios envolve um estágio que produz muitos resultados temporários que são processados por um estágio posterior. A execução desses estágios em série pode esgotar a memória disponível. Executá-los em paralelo permite que o segundo estágio liberte memória enquanto processa os resultados.

Por fim, à medida que adicionamos mais caches às nossas arquiteturas, os threads podem ficar ociosos quando ocorre uma falha de cache durante o acesso à memória. Isso dá tempo para que outro thread seja ativado e faça algum trabalho.

Os principais benefícios do multiencadeamento sobre o multiprocessamento incluem

  • memória compartilhada
  • menos sobrecarga para troca de contexto
  • abstração mais fácil

A maioria dos sistemas operacionais modernos também oferece algum método de compartilhar memória entre processos. Mesmo assim, permitir que o sistema operacional ou a máquina virtual alterem os threads em vários processadores, quando disponíveis, é muito atraente. Por exemplo, quando você move um programa Java multiencadeado de uma máquina de núcleo único para uma com vários núcleos, a JVM utilizará automaticamente esses outros núcleos.

    
por 02.08.2013 / 19:01
fonte
2

Parece haver alguns equívocos sob sua pergunta.

  • Embora seja possível ter uma arquitetura em que cada CPU tenha sua própria memória dedicada, esse não é o caso dos processadores multi-core. Você pode encontrar essa arquitetura ao trabalhar com supercomputadores ou clusters de computação. Em um processador multi-core, cada núcleo tem seu próprio cache, mas a maior parte da memória (toda a RAM) é compartilhada entre os núcleos. Isso significa que é possível que dois encadeamentos do mesmo processo (aplicativo) estejam sendo executados em diferentes núcleos ao mesmo tempo.
  • Não é a CPU que seleciona uma tarefa a ser executada, mas é (o agendador) o sistema operacional que seleciona as tarefas a serem executadas em cada CPU. Nesta seleção, apenas as tarefas serão consideradas quando o sistema operacional souber que a tarefa pode fazer algum progresso. As tarefas que aguardam algo (uma operação de E / S concluída, um bloqueio a ser liberado, etc.) não serão consideradas para o planejamento até que o sistema operacional saiba que a condição foi satisfeita.

Para responder às suas perguntas:

  1. Geralmente, é recomendável ter um thread separado para interação do usuário que não faça cálculos de execução demorada ou bloqueie potencialmente a E / S, pois isso melhora a capacidade de resposta percebida do aplicativo.
    Também pode ser vantajoso ter vários encadeamentos que executam cálculos, porque eles podem ser executados em diferentes núcleos (se houver vários núcleos disponíveis) e podem simplificar o design do aplicativo, o que é uma vantagem mesmo se você tiver apenas um CPU única.
  2. O multiencadeamento é geralmente preferido em relação a vários processos, porque a comunicação entre threads é geralmente mais fácil de entender / especificar do que a comunicação entre processos, porque os threads compartilham a mesma memória. Além disso, dependendo da implementação do encadeamento no SO, a alternância de tarefas entre encadeamentos pode ser mais eficiente do que a alternância de tarefas entre os processos.
por 02.08.2013 / 19:39
fonte
0

Existem várias razões pelas quais as pessoas começaram a usar threads além de fazer I / O. Uma das razões é que é supostamente mais fácil programar se você estiver acostumado a um mundo com um único encadeamento. Trabalhar com muita E / S em um único processo nos tempos antigos significaria criar máquinas de estado muito elaboradas que eram difíceis de depurar e entender. Além disso, se você fizer essa máquina de estado, terá que dividir seus cálculos em pequenos pedaços, já que uma longa computação pode deixar sua aplicação sem resposta. O antigo Netscape Navigator foi feito assim.

Threads diferentes geralmente podem usar núcleos diferentes, portanto, se você tiver operações limitadas pela CPU sem muita E / S, essas operações poderão ser executadas em um núcleo diferente sem bloquear o restante do seu aplicativo. É o oposto do que você disse, então acho que o que você está pensando em threads é o que em alguns lugares é chamado de threads verdes, ou seja, threads que não são agendados pelo sistema operacional. Um trecho de código é executado até que ele desista do controle, ou seja, executa E / S ou rendimentos.

Agora, existem várias razões pelas quais as pessoas preferem às vezes multithreading ao multiprocessamento. Processos geralmente não compartilham memória, então muitos estilos de programação não são possíveis. Em vez de atualizar uma estrutura de dados na memória, você precisa enviar uma mensagem para outro processo e o outro processo deve interpretá-la. É assim que muitas linguagens funcionam hoje e são ótimas para muitas coisas, mas é um estilo de programação diferente. Outra razão é que os processos geralmente são mais pesados e exigem mais recursos do que os threads. Você pode ter seu aplicativo com centenas de threads, mas geralmente não pode ter centenas de processos.

    
por 04.08.2013 / 17:29
fonte
0

Quando se trata de entender o processamento paralelo (vou usar esse termo como um termo genérico), é melhor começar com o básico. Vá devagar e simples no começo.

Eu entendo que threads e processos são praticamente os mesmos, mas threads são um sistema de trabalho leve, enquanto os processos são pesados. Estes são os termos usados para indicar quanto trabalho de sistema deve ser gerado para suportar esses arranjos de trabalho. Esse é um assunto importante porque o processamento paralelo faz com que o computador tenha algum trabalho extra. Se uma tarefa gerar muitos encadeamentos, isso será mais eficiente do que se fosse necessário gerar um número igual de processos para fazer o mesmo trabalho.

Tente entender a E / S no sentido mais amplo possível. Não é apenas sobre a entrada do usuário, ou E / S para dispositivos de armazenamento em massa (disco). Do ponto de vista da CPU, uma leitura da memória principal é E / S. Uma leitura de cache também é E / S, até mesmo o cache de nível 1 mais rápido. O processamento paralelo permite que o trabalho produtivo continue mesmo se um encadeamento (ou processo) estiver aguardando a E / S, porque outros encadeamentos não bloqueados podem continuar a executar.

E nunca fique preso pensando que você sabe ou controla a ordem de execução dos tópicos que você gera! Embora você possa forçar a sincronização de tarefas paralelas, faça isso apenas se a lógica do problema exigir isso. A sincronização retarda o ritmo de execução do programa e é ruim, a menos que seja estritamente necessário.

A maioria das CPUs modernas são feras complexas internamente e vão quebrar até mesmo as instruções da linguagem Assembly em microinstruções.

Todas as conversas de vários CPUs versus núcleos utilizando CPUs são apenas coisas de implementação de hardware. Mesmo uma única CPU, baseada em não núcleo, pode frequentemente fazer uso muito eficaz de software paralelo. Apenas requer suporte a SO e aplicativos.

A hierarquia grosseira da potência do processador (em ordem crescente de poder de execução da instrução) é:

  1. CPU única, sem vários núcleos
  2. CPU múltipla, sem vários núcleos
  3. CPU única, multi-core
  4. Várias CPUs, vários núcleos

Por quê? CPUs de múltiplos núcleos podem rotear tarefas para núcleos internos muito mais rápido do que o necessário para enviar uma tarefa para uma CPU diferente. Além disso, as CPUs de vários núcleos compartilham rotineiramente os níveis de cache, mais do que as CPUs de um único núcleo. Isso permite um compartilhamento de dados mais rápido também.

As métricas cruas que vi dizem que enviar uma tarefa de um núcleo para outro, dentro de uma única CPU, é aproximadamente 10 vezes mais rápido do que ter que enviar essa tarefa para outro processador.

Note também que as arquiteturas de nada compartilhado, como os supercomputadores usam rotineiramente, abstraem isso ainda mais. Então você tem vários computadores inteiros trabalhando juntos como uma unidade coordenada. O poder de processamento da instrução aumenta, assim como a sobrecarga de comunicações entre processos (IPC). Isso é diretamente análogo ao aumento de energia com sobrecarga IPC atendente encontrada entre vários CPUs de um único núcleo e um CPU multi-core. Tudo encontrado em um único computador com um único sistema operacional.

Aqui estão algumas diretrizes gerais para programar o processamento paralelo:

  • implemente quantas tarefas paralelas puder, conforme a lógica permitir;
  • fique longe de tentar coordenar o número de subtarefas que você gera para correlacionar com o design atual da CPU;
  • fique longe de adivinhar as habilidades de processamento de instruções da CPU;
  • fique longe da sincronização do processo sempre que possível;

Na verdade, é um bom padrão de design não projetar para o seu hardware atual, tanto quanto possível. O software pode ter uma vida útil muito longa, enquanto o hardware tem uma vida útil relativamente curta e fixa. Portanto, aposte (gastando tempo com) o software mais do que o hardware. O hardware vai mudar, você pode contar com isso.

    
por 31.03.2014 / 21:37
fonte