RICARDO DE MAGALHÃES SIMÕES - Sobre o Autor
Doutorando em Engenharia Elétrica, Mestre em
Informática (2006) e Bacharel em Ciência da Computação (2003), todos
pela Universidade Federal do Espírito Santo. Atualmente, Professor
Substituto de Informática no CEFET-ES, Professor de
Programação I no Curso Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas à Distância no CEFET- ES, professor de
Sistemas Operacionais pela ESAB. Tem experiência na área de Ciência da
Computação, com ênfase em Desenvolvimento de Algorítmos, Educação de
Informática para estudantes do Ensino Médio, atuando principalmente nos
seguintes temas: Informática Básica, Programação nas linguagem C/C++/C#,
Java, Pascal.
Página pessoal:
Curriculo Lattes::
UNIDADE 7
Objetivo: Aprender como é realizada a comunicação
entre os processos e threads em execução no computador, e a maneira como
ela é implementada em alguns sistemas operacionais.
1. Introdução
A comunicação entre os processos e threads é muito
importante, pois é uma das ferramentas que torna possível a execução de
várias tarefas simultaneamente no computador. A comunicação é utilizada
quando um processo ou uma thread precisa passar, ou solicitar, algum
dado que só pode ser informado por outro processo ou outra thread, por
exemplo, o gerenciador de impressão deve ser feito de tal forma que a
comunicação entre os seus processos seja eficiente, caso contrário a
utilização da impressora ficará comprometida.
Como foi visto anteriormente, tanto o sistema
operacional quanto o programa devem ser construídos de maneira que a
comunicação entre os processos e threads possa ser realizada. Para
permitir isso, o sistema operacional é feito com várias rotinas que
realizarão o gerenciamento da comunicação. Essas rotinas são acessadas
pelos programas através das API's do sistema operacional. Assim, os
programas possuem funções especiais, além das específicas, que
realizarão a comunicação no momento desejado.
A API do sistema operacional MS-Windows, denominada Win32, possui um sub-conjunto
de rotinas chamada COM (Component Object Model, Modelo de Componente de
Objeto) e possui as funções necessárias para realizar a troca de dados
entre os processos e threads. Nos sistemas UNIX a API POSIX possui dois sub-conjuntos de funções, um para o tratamento de processos, POSIX Core Services, e outro específico para o tratamento de threads chamado POSIX-Thread ou PThread. E no MacOS X as funções estão agrupadas no subconjunto Core Foundation.
2. MS-Windows Component Object Model
Nas primeiras versões do MS-Windows a
API possuía um subconjunto de funções para a comunicação entre os
processos denominada DDE (Dynamic Data Exchange, Troca Dinâmica de
Dados). Essas funções ofereciam um conjunto básico e simplificado para
realizar a troca de dados entre os processos de um programa, e entre
processos de programas diferentes. Com o lançamento do MS-Windows 3.1 em 1992 um novo conjunto de rotinas para troca de informações entre os processos foi criado, sendo chamado de COM.
As rotinas da COM são incluídas nos programas por
meio de componentes, como por exemplo, para ler o conteúdo de um arquivo
texto. Para realizar a leitura do arquivo para um programa, a rotina de
leitura possui os itens necessários: mecanismo de busca do arquivo no disco-rígido, função para copiar os dados do disco-rígido
para a memória principal, entre outros. Um outro componente que está
disponível nas rotinas da COM é o temporizador, que pode ser alterado
para executar uma determinada função em instantes pré-determinados.
O programador não precisa (e nem deve) se preocupar com o funcionamento
interno das rotinas da COM, o que ele precisa saber são apenas duas:
quais as informações necessárias para executar a rotina da COM, e qual
será a resposta na conclusão da rotina.
Tanto o componente para ler um arquivo, quanto o
temporizador, e todos os outros da COM, possuem os mecanismos
necessários para realizar a troca de informação entre os processos de um
programa. Um programa como o MS-Word irá executar uma
rotina da COM para abrir um arquivo, essa rotina será executada por um
processo independente (processo filho), que ao terminar, deverá avisar
ao processo (principal) que o executou, o próprio MS-Word,
indicando que a leitura do arquivo terminou, e que o conteúdo do arquivo
está disponível em uma área na memória principal. Se o arquivo não pode
ser lido no disco-rígido, a rotina da COM deverá informar o
motivo de não ter conseguido ler, que pode ser, por exemplo, a não
existência do arquivo no disco.
A COM também possui rotinas para que o programa crie
seus próprios processos, ou threads, de acordo com a implementação
feita pelo programador, e possui também rotinas para que os processos e
threads se comuniquem. Os componentes da COM ficam disponíveis aos programadores através das ferramentas de desenvolvimento de programas, como: Borland Delphi, MS-Visual
Studio, entre outras. Na prática, o que fica disponível aos
programadores são partes das rotinas, pois as rotinas completas estão no
próprio MS- Windows. Essas partes contêm apenas as regras de utilização
da rotina, que é chamada de Interface de Componente.
Essa abordagem tem vantagens e desvantagens: as
vantagens mais perceptíveis são: a economia de tempo no desenvolvimento
do programa e a diminuição do espaço ocupado pelo programa, tanto na
memória principal quanto no disco-rígido; e as desvantagens
são: a grande necessidade de espaço para o próprio sistema operacional,
e a dependência dos programas a uma determinada versão do MS-Windows, pois cada versão possui uma COM específica.
Algumas rotinas são executadas como um processo
dentro do próprio programa do usuário, e outras através dos Serviços de
Componentes, que são pequenos aplicativos executados de forma
independente, mas em sincronia com o programa do usuário.
As rotinas de comunicação do MS-Windows
Vista passarão a ter um novo nome: Windows Communication Foundation. A
mudança de nome se deve a mudanças internas na execução das rotinas de
controle de comunicação entre os processos. Por causa dessa mudança,
muitos programas feitos para o MS-Windows XP não funcionaram no MS-Windows
Vista. As alterações visavam obter melhorias no desempenho dos
programas, e melhor aproveitamento dos recursos do computador, visto que
a maioria dos computadores atuais possui um processador com a
capacidade de execução de várias threads simultaneamente, e alguns
processadores com mais de um núcleo podem executar mais de um processo
simultaneamente.
3. POSIX Core Services
O padrão POSIX foi formalizado em 1990, definido para
se criar um padrão de funcionamento entre as diversas versões do
sistema Unix existentes na época. O POSIX tornou-se um
padrão entre os sistemas Unix, sendo adotado praticamente por todos os
sistemas, não havendo exceções de importância. As versões iniciais do
POSIX continham rotinas para o gerenciamento de processos, permitindo
a criação de vários simultaneamente e a troca de dados entre eles. A
execução dos processos é feita, desde o início, utilizando-se a técnica de compartilhamento do tempo do processador. Essas rotinas receberam o nome de POSIX Core Services.
Para os programadores de aplicativos, as rotinas de
gerenciamento dos processos são acessadas a partir de bibliotecas de
funções. Estas são semelhantes aos componentes COM, as diferenças dizem
respeito mais a questões conceituais do que práticas. As rotinas que
fazem parte do POSIX Core Services permitem aos programadores criarem
programas que podem ser utilizados em sistemas HP-UX (Unix da Hewllet-Packard) e IBM AIX, ou qualquer uma das principais distribuições do sistema Linux.
Os programas feitos utilizando tais rotinas podem
ser executados em diversos sistemas Unix, pois em todos eles as rotinas
possuem a mesma definição para os parâmetros de entrada e a mesma
definição para o resultado delas. Internamente cada rotina será feita de
acordo com os critérios das respectivas equipes de desenvolvimento de
cada empresa. Para realizar o gerenciamento de threads nos sistemas
Unix, foi criado um outro conjunto de rotinas denominado POSIX Threads.
Este novo conjunto permite que um mesmo processo possa criar várias
threads de execução, otimizando a utilização dos recursos do computador.
Um detalhe importante: os programas só funcionarão
em sistemas Unix diferentes se possuírem apenas as rotinas disponíveis
no POSIX. A utilização de rotinas específicas, ou proprietárias, não
definidas no padrão POSIX pode tornar um programa feito para um sistema
incompatível com outro sistema. Imagine um sistema Unix hipotético
chamado BRIX utilizado para monitorar um processo industrial. Esse
sistema conterá algumas rotinas específicas para o seu funcionamento. Se
um aplicativo for feito para realizar alguns controles adicionais na
indústria, como por exemplo, o controle de estoque, utilizando estas
rotinas, ele só poderá ser utilizado no sistema BRIX. Para o programa
ser compatível com vários sistemas Unix, os sistemas que irão executá-lo devem possuir os mesmos conjuntos de rotinas.
4. MacOS X Core Foundation
No MacOS X as principais rotinas de gerenciamento do
sistema são agrupadas na Core Foundation. Ela possui os tipos de dados
fundamentais e serviços essenciais para realizar a correta execução dos
programas no computador. As rotinas são definidas como “Objetos
Gerenciados pelo MacOS X”, e acessíveis aos programadores graças às
ferramentas de desenvolvimento disponíveis para os computadores
Macintosh, quando for necessária uma utilização direta das funções
contidas na Core Foundation. Os objetos são definidos de modo altamente
abstrato, permitindo um grande grau de independência entre as versões do
Mac OS X (atualmente está na 5ª versão).
A Core Foundation oferece suporte tanto aos
aplicativos quanto ao próprio sistema operacional, sendo que algumas
funções são realizadas através de rotinas incluídas nos programas, e
outras rotinas são executadas pela própria Core Foundation, por meio de
utilitários denominados Serviços do Sistema. Estes serviços são
semelhantes aos Serviços de Componente do MS-Windows XP.
Uma característica importante da Core Foundation nos
computadores Macintosh é a manutenção da compatibilidade com aplicativos
desenvolvidos para os sistemas operacionais anteriores ao MacOS X.
Antes do MacOS X os computadores Macintosh utilizavam o sistema
operacional MacOS System. Aplicativos simples, que não utilizam
comunicação entre processos são gerenciados por um conjunto de rotinas
denominadas Carbon, mas o Carbon não possui a capacidade de gerenciar a
comunicação entre processos de aplicativos antigos, essa tarefa é feita
pela Core Foundation de maneira totalmente transparente, não havendo a
necessidade de alterações no programa original.
Nenhum comentário:
Postar um comentário