significa que o framework ou linguagem de programacao que voce esta usando implementa o conceito.VantagensMais rapidas do que criar novos processos, pois nao necessita de alocacao de recursos, ja que compartilham o mesmo espaco de enderecamento. Concorrencia entre subrotinas do processo. Real paralelismo em maquinas multicore(apenas threads kernel).DesvantagensAcesso compartilhado aos recursos. Threads em modo usuario ao realizarem i/o bloqueiam o processo inteiro.Outro problema com threads em SO ruins, e que criar e devagar. Solaris e Windows podem criar threads mais rapidos que processos, mas ainda continua devagar. Entao o que os servidores web baseados em thread fizeram? Eles inventaram as thread pools.Uma thread pool funciona como uma pre criacao. As threads sao criadas em blocos no comeco do programa e o trabalho e distribuido eventualmente. Quando existem mais conexoes do que threads, as novas conexoes precisam esperar. Mas pelo lado positivo, voce evitou o custo de criacao. Isso nao parece ser muito escalavel, parece?Exemplo em pseudo codigo que exemplifica a utilizacao de threads por servidores web.Thread para despacho de requisicoes.enquanto(verdade) { Obter_proximo_pedido( &buf ); Iniciar_Worker_Thread( buf );}Thread para atender requisicoes.enquanto(verdade) { Esperar_Trabalho ( &buf ); Look_for_page_cache(&buf,&page); se (page_not_in_cache (&page) Read_page_from_disk( &buf, &page); retornar _page( &page );}Para ler um pouco mais sobre threads, veja essa apresentacao:'Event-drive' programming Esse e um outro paradigma que foge aqueles tres citados no comeco desse post. Nesse metodo voce escalona a cpu e os recursos que quiser aplicar para cada conexao. Como fazer isso depende da sua aplicacao e nem sempre e possivel ou sensato fazer isso. Mas se voce conseguir capturar o estado(sessao) de cada conexao e dividi-las em pequenas pecas, entao essa solucao sera melhor aplicada. Se as suas conexoes nao requerem muito ou nenhuma secao, entao esta e a ideia perfeita para voce.pros: eficiente e elegante escala bem - centenas de conexoes dizem somente centenas objectos de socket/estado e nao uma centenas de processos. nao requer barramentos em recursos compartilhados. se integra facilmente com a api do windows baseada em eventos. contras: mais complexo - voce tem que criar uma maquina de estados. requer um paradigma de programacao diferente que pode ser confuso de inicio.Entao... como funciona? Para explicar esse fato, usarei as palavras referidas por Sam Rushing.Imagine o seu programa como uma pessoa. Imagine tambem que existe dois baldes vazios, um na frente e um atras. O balde da frente sera enchido com agua e o trabalho da pessoa e esperar que esse balde fique cheio e o despeje no balde de tras. O balde frontal enche-se esporadicamente, algumas vezes muito rapido,e algumas vezes muito devagar, mas em geral o seu programa fica parado a maioria do tempo.Agora, e se o seu programa precisa se comunicar com mais de uma conexao ou arquivo ao mesmo tempo? Criando um novo processo e equivalente a colocar uma nova pessoa para cada par de baldes. Um tipico servidor e escrito dessa forma! Um servidor pode estar manipulando 20 conexoes simultaneas, e na nossa metafora isso significa uma linha de 20 pessoas ociosas, 99% do tempo, cada uma esperando o seu balde encher!A solucao obvia para esse problema