Sistemas Operativos /2006. Trabalho Prático v1.0

Transcrição

1 Instituto Politécnico de Viseu Escola Superior de Tecnologia de Viseu Engenharia de Sistemas e Informática Sistemas Operativos /2006 Trabalho Prático v1.0 Introdução O presente trabalho prático visa uma maior familiarização com a programação de mecanismos de sincronização e comunicação entre processos no ambiente UNIX/Linux. Poderá ser realizado em grupo, constituído por um número máximo de 3 alunos. O trabalho está sujeito a apresentação e defesa, realizada individualmente por cada aluno. É, obviamente, interdita a cópia parcial ou integral de trabalhos e, a ser detectada, conduzirá à adequada penalização dos envolvidos. O trabalho deverá apresentar-se na forma de código fonte e de um relatório claro e conciso, que também será objecto de avaliação. Chama-se à atenção para o facto de este enunciado poder ainda sofrer pequenas alterações. Os alunos poderão aperceber-se de eventuais actualizações, vigiando a respectiva versão. Para os alunos mais desatentos, refira-se que a execução deste trabalho prático, para além de constituir elemento de avaliação, representa também uma forma efectiva de preparação para as provas de avaliação. Contextualização As especificações apresentadas neste enunciado não correspondem à solução mais simples ou eficiente, devendo ser encaradas como um pretexto para conjugar, num único trabalho prático, um conjunto alargado de mecanismos de comunicação estudados, nomeadamente, ficheiros, sinais, pipes unidireccionais standard, pipes nomeados (FIFO), filas de mensagens, memória partilhada e semáforos. De modo a simplificar a avaliação deste trabalho, as indicações devem ser integralmente respeitadas. É, contudo, admissível que sejam tomadas opções diferentes, desde que, claramente, não representem uma forma de contornar algum dos aspectos em estudo. Estas opções devem encontrar-se devidamente fundamentadas no respectivo relatório. As opções tomadas no sentido de resolver circunstâncias que aqui não sejam explicitadas deverão, também, ser devidamente documentadas. Descrição do problema O contexto de utilização desta aplicação poderia, por exemplo, corresponder a uma redacção de um jornal. Várias agências noticiosas enviam notícias à redacção. As agências noticiosas classificam previamente as notícias por tópicos, como, por exemplo, política, sociedade, desporto, educação, etc. Os jornalistas da redacção, especializados em determinados tópicos, devem ser notificados aquando da recepção de novas notícias nesse tópico. Esta aplicação é constituída por vários programas que interagem entre si, conforme esquematizado na Figura 1. Todos os processos são executados num mesmo equipamento Linux e utilizam os mecanismos IPC estudados nas aulas práticas da disciplina. O programa Servidor serve de plataforma de difusão das notícias no seio da redacção. Cada programa leitor de notícias (Leitor) subscreve um ou mais tópicos. Sempre que uma notícia é publicada num tópico, todos os subscritores recebem a correspondente notificação. Se o programa leitor pretender ter acesso ao conteúdo da notícia, este comunica directamente com o programa associado a uma agência noticiosa (Agência). O programa Monitor visualiza um conjunto de estatísticas e informações adicionais sobre a utilização desta aplicação. 1/5

2 Figura 1 Implementação Na interacção entre estes processos são definidos vários mecanismos de comunicação de acordo com a Figura 2. Figura 2 Programa Servidor Processo Pai: Na fase de inicialização, este processo deve preparar convenientemente a estrutura de dados e criar todos os recursos necessários à comunicação entre processos. A lista de tópicos a serem considerados deve constar num ficheiro de texto. Todos os dados de configuração da aplicação (chaves de recursos IPC, subdirectoria de FIFO, etc) devem ser armazenados num ficheiro de texto para que possa ser consultado pelos restantes programas. Em seguida, este processo entra em ciclo ficando bloqueado à espera de mensagens (P1, P2) na fila de mensagens 1. Após a recepção de uma mensagem, lança um processo filho que tratará de responder ao processo que efectuou o pedido. Ao receber o sinal SIGINT, deve terminar, libertando todos os recursos que tiverem sido alocados. Processo Filho: 2/5

3 Este processo analisa a mensagem e responde de acordo com os seguintes tipos de mensagens: Lista tópicos: Este pedido tem origem em processos Agência (P1) ou Leitor (P2). O processo envia uma resposta (R1 ou R2) com a lista de tópicos definidos no Servidor. Subscreve tópico: Este pedido tem origem em processos Leitor (P2) que desejam subscrever um tópico. Não é necessário uma resposta de confirmação da subscrição. Cancela tópico: Este pedido tem origem em processos Leitor (P2) que desejam cancelar a subscrição de um tópico. Não é necessário uma resposta de confirmação do cancelamento da subscrição. Lista subscrições activas: Este pedido tem origem em processos Leitor (P2) com a indicação do PID do processo filho que recebe as notificações de novas mensagens. É enviada uma resposta (R2) com a lista de tópicos subscritos. Lista de notícias por tópico: Este pedido tem origem em processos Leitor (P2) com indicação do tópico pretendido. É enviada uma resposta (R2) com a lista de notícias desse tópico. A lista inclui o número da notícia e o respectivo título. Processo servidor de notícia: Este pedido tem origem em processos Leitor (P2) com indicação do número da notícia pretendida. É enviada uma resposta (R2) com o PID do processo filho Agência que serve o pedido de conteúdo da notícia. Publica: Pedido de publicação de uma notícia num determinado tópico com origem em processos Agência (P1). A mensagem correspondente a este pedido deve incluir o tópico, o título da notícia e o PID do processo que responderá a uma solicitação do conteúdo da notícia (PID do processo filho Agência). O processo envia uma resposta (R1) com a indicação do número da notícia (único no sistema). Envia, em seguida, para todos os processos Leitor que tenham subscrito o tópico, uma mensagem (N1) com informação do número da notícia e do respectivo título (difusão). Programa Agência Este programa permitirá às agências noticiosas, por um lado, solicitar a publicação de uma notícia num determinado tópico e, por outro, servir os vários processos Leitor que pretendam aceder ao conteúdo de uma notícia. As notícias estão previamente armazenadas em ficheiros de texto. Quando lançada a execução deste programa, deve, através da função fork(), lançar um processo filho. O processo pai será responsável pela interacção com o utilizador. O processo filho será responsável pela disponibilização do conteúdo de uma notícia solicitado por um processo Leitor. Processo pai: O processo pai disponibiliza uma linha de comandos (prompt) que permitirá ao utilizador introduzir os seguintes comandos: lt: Pedido ao Servidor da lista de tópicos. pb <topico> <ficheiro>: O pedido de publicação de uma notícia, num determinado tópico, é enviado ao Servidor (P1), obtendo deste um número de notícia que é único no sistema. A informação a enviar ao Servidor inclui o tópico, o título da notícia (1ª linha do ficheiro de texto) e o PID do processo filho que disponibiliza o conteúdo da notícia. Tal pedido é solicitado ao servidor através da fila de mensagens 1. O servidor responde (R1) com um número da notícia e fará a difusão da mesma pelos processos Leitor subscritores (N1). Recebida a resposta do servidor, o processo pai, através de um pipe unidireccional, envia ao filho a informação sobre o nome do ficheiro e o respectivo número da notícia e sinaliza tal facto com o envio de um sinal. O processo filho manterá esta informação numa tabela, permitindo-lhe responder a solicitações de conteúdos de notícias. s: Este comando termina o processo, devendo enviar um sinal ao processo filho para que termine a sua execução. Processo filho: Atende a pedidos (F1) de conteúdo de notícias colocadas na fila de mensagens 2. Quando recebe uma mensagem, esta contém o número da notícia e o remetente (PID do processo Leitor). Depois de identificado o ficheiro de texto com o conteúdo da notícia, cria um pipe nomeado (FIFO) para a transferência do conteúdo. Envia uma mensagem de resposta (F2) para o processo Leitor a confirmar a disponibilidade da notícia. Coloca no FIFO, o conteúdo do ficheiro de texto correspondente à notícia. A identificação do pipe nomeado coincide com 3/5

4 o PID do processo Leitor e é criado numa subdirectoria definida pelo programa Servidor (do conhecimento de ambos os processos comunicantes por consulta do ficheiro de configuração). Deve ser considerado um número máximo, configurado pelo servidor, de pipes nomeados em utilização simultânea. O controlo deste número máximo deve ser assegurado por semáforos. Programa Leitor Este programa permitirá aos jornalistas, por um lado, utilizar os serviços da aplicação (listar, subscrever e cancelar tópicos) e, por outro, solicitar à agência noticiosa o conteúdo de uma determinada notícia. Processo pai: O processo pai disponibiliza uma linha de comandos (prompt) que permitirá ao utilizador introduzir os seguintes comandos: lt: Pedido ao Servidor da lista de tópicos. nt <tópico>: Pedido ao Servidor da lista de notícias publicadas neste tópico. sb <tópico>: Pedido ao Servidor da subscrição de um tópico. Para além do tópico, a mensagem enviada deve incluir o PID do processo filho que irá receber as notificações de novas notícias (subscrição). Não é necessário uma resposta de confirmação da subscrição. csb <tópico>: Pedido ao Servidor do cancelamento da subscrição de um tópico. Não é necessário uma resposta de confirmação do cancelamento da subscrição. lts: Pedido ao Servidor da lista de tópicos subscritos. Para além do tópico, a mensagem enviada deve incluir o PID do processo filho que irá permitir ao Servidor identificar quais os tópicos que foram subscritos. vnt <número notícia>: Pedido do conteúdo de uma notícia. Em primeiro lugar, é solicitado ao Servidor o PID do processo filho Agência que serve o pedido de conteúdo da notícia. Recorrendo a este PID, envia uma mensagem, através da fila de mensagens 2. Recebida a confirmação da disponibilidade da notícia, abre o pipe nomeado criado numa subdirectoria definida pelo programa Servidor (ambas do conhecimento dos processos comunicantes). O nome do FIFO coincide com o PID deste processo. O conteúdo da notícia é lido do FIFO e visualizado no monitor. Terminado o processo de transferência, o FIFO é eliminado. s: Este comando termina o programa, devendo enviar um sinal ao processo filho para que termine a sua execução. Processo filho: O processo filho aguarda por mensagens colocadas na fila 2 que dizem respeito a notificações fornecidas pelo Servidor quando uma nova notícia é publicada num tópico que tenha sido subscrito por este programa. A notificação de uma notícia é visualizada no monitor (tópico, número e título). Programa Monitor: Para que o processo Servidor possa responder às solicitações, uma estrutura de dados deverá ser mantida em memória. Esta memória deve ser partilhada, permitindo ao programa monitor exibir, periodicamente (de 3 em 3 segundos), um conjunto de dados estatísticos sobre a utilização da aplicação. Devem constar, de entre outras informações que se julguem por convenientes, o número de notícias por tópico e o número de subscritores por tópico. Especificações Adicionais Em condições normais de execução, o programa Servidor deve ser colocado em execução antes do lançamento dos programas Agência, Leitor e Monitor. Uma das suas tarefas consiste na criação e inicialização dos mecanismos de comunicação, nomeadamente: memória partilhada: com o tamanho necessário para a manutenção da estrutura de dados necessária para a aplicação; filas de mensagens; semáforos: para controlo de diversos aspectos, dos quais se destacam: a exclusão mútua no acesso à memória partilhada; a garantia de que nunca existirão mais do que k pipes nomeados (FIFO) em simultâneo, sendo k um valor configurável à partida. 4/5

5 Uma vez criados estes recursos, as respectivas identificações devem ficar disponíveis num ficheiro de configuração (ficheiro de texto) acessível aos restantes programas que constituem esta aplicação. A estrutura de dados deve atender aos seguintes limites: Número máximo de tópicos: 10. Número máximo de caracteres para um tópico: 20. Número máximo de caracteres para um título: 50. Número máximo de notícias por tópico: 10. Número máximo de subscritores por tópico: 10. Número máximo de notícias que são mantidas no processo filho Agência:10. Dada a existência destes limites, sugere-se que sejam sempre guardados os dados mais recentes. Assim, quando, por exemplo, o número de subscritores por tópico ultrapassa o valor limite (10), é eliminada a subscrição mais antiga. Se, por exemplo, o número de notícias por tópico for ultrapassado, é eliminada a notícia mais antiga. Estas eliminações não devem ser comunicadas aos restantes programas. É assumida a possibilidade de ocorrerem algumas inconsistências. Por exemplo, o conteúdo de uma notícia já não pode ser obtido, embora permaneça na estrutura de dados da aplicação. Tratamento de erros Em acréscimo ao normal controlo de erros nas aplicações, a implementação deste trabalho deverá também contemplar o tratamento de determinadas situações de anomalia. A título indicativo, apresentam-se alguns exemplos: execução dos programas Agência, Leitor e Monitor, antes de lançar o programa Servidor; tentativa de utilizar um recurso de IPC entretanto removido; permanência de chaves de IPC resultantes de execuções passadas mal sucedidas; erros nos pedidos feitos ao servidor (listar notícias de um tópico que não existe, subscrever um tópico que não existe, etc); erros nos pedidos de conteúdos de notícias que já não podem ser servidas. Terminação dos processos e libertação de recursos Dada a importância associada à remoção dos recursos de comunicação, que por algum motivo permaneçam indevidamente alocados, aconselha-se a criação de um pequeno programa auxiliar que, quando invocado, desempenhe essa função. Durante a fase de desenvolvimento do trabalho e tendo em atenção as considerações feitas nas aulas relativamente a este assunto, os alunos devem vigiar sistematicamente a eliminação das chaves desnecessárias. Qualidade do código O código deve ser construído de forma a tornar simples não só o seu desenvolvimento como a própria leitura/avaliação. Devem ser usados comentários (de forma coerente e consistente) de modo a que, por um lado, se torne fácil a interpretação de passagens mais complexas e que, por outro, se demonstre que quem escreveu as respectivas instruções está consciente da sua semântica e implicações. Este aspecto será relevante na avaliação do trabalho. Relatório O relatório, que se pretende breve, deverá justificar as opções tomadas, bem como eventuais desvios relativamente às especificações constantes deste enunciado. Devem ser identificadas as principais dificuldades encontradas e respectivas soluções (quando não mencionadas neste enunciado). No caso do trabalho entregue não implementar todos as especificações referidas, as respectivas lacunas deverão necessariamente fazer parte desse relatório. Bom trabalho!! 5/5