Resenha sobre artigo: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor
Autor: Daniel Carrara | Publicado: 2010-04-22T08:49:00-07:00

Olá pessoal, A partir de hoje vou postar algumas trabalhos que tenho feito no mestrado e acho que pode contribuir com o meio acadêmico e tecnológico.Hoje, vou postar uma resenha que escrevi para a disciplina de SO sobre o artigo: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor.Caso queiram ler o artigo original esse é o link: http://www.sagecertification.org/publications/library/proceedings/usenix-nt98/full_papers/zabatta/zabatta.pdfRESENHAResenha sobre a obra: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor. Autores: Fabian Zabatta e Kevin YingA obra acima citada, um artigo, é um estudo comparativo do desempenho de threads em dois Sistemas Operacionais distintos: o Windows NT e o Solaris. O autor apresenta, através de experimentos, os resultados de desempenho de cada Sistema em distintas etapas de execução de determinados processos em situações diversas.O artigo é iniciado com um breve histórico dos processadores: custo e desempenho do mesmo. É então citada a criação do processador Pentium Pro (PPro), pelo fabricante Intel, onde o autor alega que esse é um processador de alto desempenho construído como suporte para o propósito do multiprocessamento. Em seguida, o autor aborda o assunto de multiprocessamento simétrico (SMP) definindo-o como uma arquitetura paralela primária onde os processadores compartilham a mesma unidade do sistema operacional assim como compartilham memória, barramento e dispositivos de entrada e saída. O autor aborda o conceito de processo e o define como objetos de execução, e os classifica em multitarefa quando aborda sobre concorrência e paralelismo; ainda fala sobre mutex. O autor inicia a explanação sobre os sistemas operacionais descrevendo as características dos SO’s Windows NT e Solaris, afirmando que ambos são sistemas que utilizam prioridades básicas, tempo de partida e algoritmos multitarefa para escalonar seus objetos de nível de kernel. Ao abordar o assunto de threads, o autor explica que no Windows NT a menor unidade de execução no nível de usuário é a fibra (fiber).  Assim, um thread é constituído de múltiplas fibers que conseguem acessar os threads aleatoriamente. No Solaris, a menor unidade de execução no nível de kernel é o LWP (light weight process), sendo esses os constituintes dos processos do Solaris. Diferentemente do NT, no Solaris, a menor unidade de execução no nível de usuário é a thread, e assim como as fibers, essas não executam sozinhas.  No caso do Solaris elas são implementadas e controladas pela biblioteca de sistema. A biblioteca de threads no Solaris define dois tipos de threads, a thread bound (encadeada) e a thread unbound (independente). Na seção de experimentos, o autor elenca sete experimentos que, segundo o mesmo, foram importantes para determinar se as diferenças na implementação, design e camadas de threads produziriam diferenças de desempenho significantes. São eles:1. Medida do número máximo de threads de kernel que poderia ser criada por cada sistema;2. Medida do tempo de execução da criação de threads;3. Medida da velocidade de criação de thread quando se força o processador com vários processos em execução;4. Determinar como cada implementação de threads de sistemas operacionais desempenharia em processos com threads em intensivo processamento que não requereram nenhuma sincronização;5. Determinar como cada implementação de thread desempenharia em processos de processamento intensivo que solicitaram sincronização extensa;6. Determinar o desempenho de cada implementação do sistema operacional em pesquisas paralelas implementadas com threads;7. Determinar o desempenho de cada implementação do sistema operacional nos processos com threads que tiveram os requisitos de processador espalhados.Quanto ao ambiente dos experimentos, trata-se de uma mesma máquina para ambos os sistemas, com PPro SMP e 512Mb de RAM e um grande HD. O modo de instalação do SO foi dual-boot, com as versões de Solaris 2.6 e Windows NT Server, versão 4.0. O compilador utilizado foi o GNU gcc versão 2.8.1.Para descrever os experimentos a seguir, será usado em conjunto a análise crítica dos resultados apresentados a cada etapa. O primeiro experimento mensura a quantidade máxima de objetos do nível de kernel que cada SO poderia criar. Para o NT em 24.12 segundos foram criados 9817 threads contra 2294 threads no Solaris em apenas 2.68. Contudo para o Windows foram necessários 68MB de memória enquanto no Solaris apenas 19MB. Porém, o objetivo desse primeiro processo era observar a quantidade de threads que cada sistema conseguiria criar e nesse ponto o Windows NT obteve um melhor resultado como visto acima, pois no Solaris, quando se obteve o número de 2294 apresentou uma falha.No segundo experimento foi abordada a velocidade de criação dos threads. Os sistemas operacionais Windows NT e Solaris apresentaram um desempenho parecido, no caso do Solaris para Threads agregadas. Segundo o autor isso pode ser atribuído devido o fato de que cada SO requer System Call (chamadas de sistema) para a criação dos threads. Quando o Solaris utilizou apenas uma chamada da biblioteca o desempenho do mesmo superou o NT, através dos threads independentes. Para o caso do CL=4 no Solaris apresentou um bom desempenho, porém muito inferior ao caso dos threads independentes. Com esse segundo experimento pode-se observar que para o caso dos threads independentes, onde há uma chamada à biblioteca de threads o desempenho supera o NT e até mesmo as outras formas de criação utilizadas no Solaris. Isso pode ser observado através dos tempos apresentados na tabela 2 da seção 3.2.Também abrangendo a criação de threads tem-se o terceiro teste. Nesse caso, mediu-se a velocidade de criação dos threads da mesma forma que o teste anterior, porém com sobrecarga de threads no processador. Mais uma vez nesse caso o Solaris superou o Windows NT. O terceiro experimento retrata uma realidade corriqueira para os processadores e processos e através do teste em questão se pôde observar a veracidade dos fatos.No quarto experimento foi determinado o desempenho que cada implementação de thread poderia atingir para os processos sem requisição de sincronização. O thread teria que ficar ociosa por 10 segundos até ser concluído, após sua conclusão o processo de criação poderia se findar. As diferenças entre os dois SO’s são sutis, exceto para os threads unbound, que apresentaram valores muito acima do NT.  Devido à ligação entre o thread unbound e a CL=4, essa última impactou no tempo de chamada do thread unbound o que fez com que a mesma executasse em tempo 10N.O quinto teste é semelhante ao quarto, contudo, a sincronização nesse caso é requerida. Para tanto, utilizou-se o programa “array.c” que implementa a criação de threads para modificar dados compartilhados em uma estrutura de 10.000 iterações. A cada momento que um thread necessitava modificar um dado compartilhado era requisitada uma exclusão mútua. O Windows NT apresentou dois objetos de exclusão mútua: o mutex e a sessão crítica. Já o Solaris utilizou apenas o mutex. O desempenho no Solaris foi consideravelmente melhor especialmente com o processo de CL=4. Contudo o NT apresentou bons resultados quando utilizou sessão crítica. Acredita-se que essa otimização é devido o fato de que na sessão crítica há um objeto usuário simples que apresenta um estado global.O sexto teste aborda a pesquisa paralela com threads que requisitam sincronização limitada. O autor implementa nesse teste o problema do caixeiro viajante. Os threads foram implementados no paradigma de pilha de trabalho. Como resultado, o NT apresentou um desempenho fraco quando uma sincronização foi requisitada. O interessante nesse experimento é que o NT supera ligeiramente o Solaris. Um resultado surpreendente, visto que no teste anterior, utilizando chamada síncrona o NT apresentou um desempenho inferior. Outro ponto interessante apresentado pelo autor é que utilizando uma ou mais thread unbound no Solaris o desempenho foi o mesmo que utilizando dois threads encadeados no mesmo SO.O último experimento demonstra como cada implementação de thread de sistema operacional desempenharia em processos que apresentam muitos threads com explosão (espalhamento) de CPU (bursts). Pode-se citar como exemplo os processos de E/S como, uma rede ou uma aplicação de cliente/servidor. O tempo de espera foi determinante nesse teste e no desempenho dos SO’s. O Solaris utilizando concorrência restrita apresentou um resultado um pouco melhor que o NT.Enfim, o autor conclui o estudo afirmando que ambos os Sistemas Operacionais foram aptos para a utilização de multiprocessadores. Um fator pertinente para o problema de desempenho de cada sistema foi a falta de documentação. O sistema Windows NT apresentou ótimos resultados quando se utilizou a sessão crítica, porém, na maioria dos outros testes o Solaris apresentou melhores resultados, algumas vezes muito próximo ao NT, especialmente na utilização das unbounds threads. Realmente esses aspectos foram observados no estudo. Ele cita ainda, o POSIX (Portable Operating System Interface) como solução para padronização de threads e assim, quem sabe, uma otimização gradual dos threads em todos os Sistemas Operacionais, presentes ou futuros.O estudo demonstra ainda que embora o Solaris seja um Sistema considerado em alguns pontos superior aos demais, alguns aspectos precisam ser melhores aproveitados. Já o Windows NT, um sistema criado pela Microsoft para complementar as distribuições do Windows, com foco empresarial, demonstra alguns pontos inferiores ao Solaris, contudo, o mesmo pode ser explorado para programação paralela e sessão crítica. Enfim, com esse estudo, pode-se observar que do ponto de vista de Sistemas Operacionais e seus recursos, tudo é relativo, ou seja, cada categoria de thread é melhor ou pior em determinados momentos e com determinados ambientes, tanto no Windows NT quanto no Solaris.Resenha escrita por:Daniel H. Carrara de AzevedoMestrando em IA - UFUE-mail: dhcarrara@gmail.com