Movendo o código de manipulação do mouse do X.Org numa thread separada (proposta de projeto)

Transcrição

1 Movendo o código de manipulação do mouse do X.Org numa thread separada (proposta de projeto) Tiago Vignatti 1 1 PPGInf Universidade Federal do Paraná (UFPR) Caixa Postal Curitiba PR Brazil vignatti@c3sl.ufpr.br Abstract. A properly multi-threaded X server implementation could respond to high-priority user events without being blocked on drawing operations or even low-priority I/O events. The proposed project intends to move the mouse handling code of X server into a separate thread different from the main. Resumo. Uma implementação multi-thread correta do servidor X poderia responder a eventos de alta prioridade do usuário sem serem bloqueados em operações de desenho ou até mesmo eventos de E/S de baixa prioridade. O projeto proposto tem a intenção de mover o código de manipulação do mouse do servidor X em uma thread separada da principal. 1. Introdução O X Window System, comumente chamado de X, é um protocolo que possibilita interfaces gráficas de janelas através da rede nos sistemas operacionais baseados em Unix [LINFO 2006, Scheifler and Gettys 1997]. O X é utiliza o modelo cliente-servidor: o servidor aceita requisições para os dispositivos gráficos (monitor, impressora e etc) e de entrada (teclado, mouse, tela de toque, mesa digitalizadora e etc). Por sua vez, as aplicações atuam como clientes, interagindo com o usuário e com outros clientes via servidor. Os clientes tipicamente são executados em máquinas remotas (Figura 1). A atual implementação do servidor X, o X.Org [Angebranndt et al. 2004], trata os dispositivos de entrada e as requisições dos clientes através de um loop de eventos single-threaded. Uma implementação multi-thread correta do X.Org poderia responder a eventos entrada de alta prioridade do usuário sem serem bloqueados em operações de desenho ou até mesmo eventos de E/S de baixa prioridade. Um exemplo típico dessa anomalia é quando o sistema operacional está fazendo extensas paginações da memória, deixando o movimento do mouse lento e com trepidações. O projeto proposto tem a intenção de mover a parte de manipulação dos ponteiros (i.e. mouse, trackball, mesa digitalizadora e etc) do servidor X em uma thread separada da principal. Para isso vários conceitos de sistemas distríbuidos serão tratados e também discutidos neste trabalho. 2. Tornando o servidor X multi-thread O Multi-threaded X Server [Haynes et al. 1993], chamado de MTX, foi proposto em 1993, porém não obteve o sucesso esperado. A idéia do MTX era disparar as requisições

2 Figura 1. Arquitetura do X Window System. dos clientes concorrentemente através de threads. A falha no projeto do MTX foi não ter estimado o custo da gerência das threads, pois tais mecanismos de concorrência foram utilizados em quase todas as estruturas de dados do servidor (Figura 2), sobrepujando o ganho de desempenho que era o real interesse de tal implementação [Kilgard et al. 1994]. Diferente do MTX. nosso projeto prevê a implementação de apenas uma thread dedicada aos movimentos do mouse. Nossa abordagem deve acarretar uma melhoraria geral de desempenho no sistema X (clientes e servidor) pois poucas trocas de contexto deverão acontecer. No entanto, vários cuidados com sincronia entre os eventos disparados pelos dispositivos de entrada e também com as consistência entre as threads devem ser levados em conta. Veremos esses aspectos de implementação na próxima seção. 3. Metodologia e Aspectos de Implementação A reestruturação do loop de eventos do servidor X envolve alguns assuntos fundamentais na área de sistemas distribuídos. Destacaremos alguns aqui aos quais iremos objetivar este trabalho e também algumas possíveis implementações. Sincronia entre eventos. Pelo fato do protocolo X ser assíncrono não é garantido que os eventos disparados pelos dispositivos de entrada cheguem na mesma sequência requerida. São necessários conceitos de relógio e temporização para resolver esse tipo de problema [Lamport 1978]. Esse é um problema já resolvido no X.Org single-threaded, porém com a adição de outra thread diferente da principal certamente enfrentaremos esse problema novamente.

3 Figura 2. Organização das threads do MTX. Consistência entre threads. Diferentes threads serão disparadas para cada dispositivo de entrada e será necessária mecanismos de sincronia para manter a consistência dos dados compartilhados entre as threads. Possivelmente usaremos semáfaros (IPC) [Birman 2006]. Detalharemos alguns aspectos de implementação ainda nessa seção. Transparência. O protocolo de comunicação entre o servidor X e seus clientes devem operar de maneira transparente: os clientes e o servidor devem ser executados do mesmo jeito em máquinas heterogêneas. Por exemplo: executar aplicativos gráficos em diferentes máquinas e ser controlado por apenas um monitor, teclado e mouse. Para esses casos precisamos estabelecer esquemas de Remote Procedure Calls. Certamente não podemos predizer tudo na solução do projeto e eventualmente alguns aspectos de implementação inesperados irão aparecer (razão do porquê determinaremos um tempo de contingência no cronograma). Entretanto, podemos já delinear algumas idéias de código. Iremos enumerá-las aqui: Evitar pthreads. Existiria um custo de desempenho em executar o servidor X linkado com pthreads [Lewis and Berg 1998]. Para evitar esse sobrecarregamento das bibliotecas de threads no resto do servidor X, pretendemos usar clone() [Linux Programmer s Manual 2005]. Isso trás em evidência outro problema, como veremos neste próximo item. Criando o processo filho. O problema diz a respeito da portabilidade da chamada de função clone(), como o manual afirma [Linux Programmer s Manual 2005]:

4 As chamadas clone() e sys clone é específica do Linux e não deve ser usada em programas que pretendem ser portáveis.. Nossa idéia é, portanto, usar clone() sempre que disponível e no caso de sistemas que não suportam tal chamada fazer o fallback para pthreads. Implementando os descritores de arquivos. Eventualmente a thread do mouse estará dormindo (bloqueada) enquanto nenhum evento é emitido e poderia estar esperando num laço select() que observa os arquivos de entrada. O número de descritores de arquivo será pequeno, então não é nossa prioridade se preocupar com o melhor método de monitoramento a ser utilizado. Provavelmente usaremos select() ou poll(). Ambos são fáceis de trabalhar e portáveis. Sistemas operacionais que não tenham suporte a thread. o servidor X é executado em dispositivos embarcados e também em grandes servidoras de processamento. A filosofia do servidor X é de ser portável, portanto usuário que não podem, ou não querem, usar a thread responsável pelo mouse deve ser capaz de usar uma versão single-thread do servidor X. Certamente fazer isso em tempo de compilação não é uma tarefa difícil. 4. Como garantir que tudo isso adiantou? Está no objetivo deste projeto prover ferramentas e métodos que garantam que tudo o que será implementado melhorará o desempenho total do servidor X. Um método simples seria estressar o servidor com muito desenho na tela. O servidor X sem a thread separada para o mouse terá um desempenho pior no movimento do mouse que o servidor X multi-threaded. Um porco de memória (memory hog) que consome toda a memória física disponível pode ser facilmente empregado como ferramenta de medição. Um rascunho de código do porco de memória é visto abaixo: #include <stdlib.h> #define BOMB 1024 int main (int argc, char *argv[]) { int i, j; long int *hog; } while(1) { hog = (long int *) malloc (sizeof(long int) * BOMB); } Também outros métodos analíticos poderão ser usados para conseguir uma melhor aproximação dos resultados.

5 5. Cronograma A seguir apresentamos as atividades que iremos desenvolver neste trabalho. Na tabela mostramos a duração esperada das atividades, sendo que o tempo total de duração do trabalho é de dez semanas, começando a partir do dia 16 de abril de 2007 e finalizando em 26 de julho. Existe um tempo de contingência de 1 semana para eventuais atrasos e outros problemas. Descrição Levantamento de artigos e materiais Estudo do comportamento da infraestrutura de entrada do servidor X Fase de Projeto Implementação Redação do artigo Contingência Revisão 6. Conclusão Ao adicionar uma thread separada dedicada aos movimentos do mouse no X.Org, esperase um acréscimo no desempenho total do servidor. Mesmo que o servidor X.Org esteja sendo executado com baixa prioridade, esperamos que o movimento do mouse seja suave e sem trepidações, fatos comumente não observados na implementação atual. Para garantir essa melhoria do desempenho, usaremos alguns mecanismos que consomem toda memória física do sistema. Em possíveis trabalhos futuros, o teclado e outros dispositivos de entrada também poderão ser adicionados numa thread separada, tomando os respectivos cuidados e com o mesmo objetivo de melhorar o desempenho do X Window System. Referências Angebranndt, S., Drewry, R., Karlton, P., Newman, T., Scheifler, B., Packard, K., and Wiggins, D. (2004). Definition of the Porting Layer for X v11 Sample Server. X Consortium, Inc, and X.Org Foundation. Birman, K. (2006). Reliable Distributed Systems Technologies, Web Services, and Applications. Springer. Haynes, M., Chiba, H., Layne, P., Harada, A., Kanaoka, R. P. H., Smith, J. A., and Miyake, T. (1993). Component Design Specification for the MIT Multi-Threaded X Window Sample Server. Data General Corporation, Omron Corporation, and MIT X Consortium. X server multi- Kilgard, M. J., Hui, S., Leinwand, A. A., and Spalding, D. (1994). rendering for OpenGL and PEX. The X Resource, 9(1): Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):

6 Lewis, B. and Berg, D. J. (1998). Multithreaded programming with pthreads. LINFO (2006). The X Window System: A Brief Introduction. The Linux Information Project. Linux Programmer s Manual (2005). clone() man page. Scheifler, R. W. and Gettys, J. (1997). X Window System: core and extension protocols. Digital Equipment Corp., Acton, MA, USA.