POSIX Queue

Esse é o 18º artigo da série Comunicação entre Processos. Nesse artigo é abordado o uso da POSIX Queue.

POSIX Queue é uma padronização desse recurso para que fosse altamente portável entre os sistemas. Não difere tanto da Queue System V, mas possui um recurso de notificação assíncrona.

Systemcalls

Para que essas systemcalls funcione é necessário linkar com o a biblioteca rt.

Permite a criação da queue de modo simplificado, ou de modo configurado.

Permite que a mensagem seja enviada para a queue. Existe uma variante com parâmetro de timeout

Permite que a mensagem seja lida da queue. Existe uma variante com paramêtro de timeout

Diferente da Queue System V, a queue do POSIX permite notificar o recebimento da mensagem de forma assíncrona

Permite realizar a leitura dos atributos da Queue.

Permite parametrizar uma queue, podendo realizar um backup das configurações atuais.

Fecha o descritor da queue

Remove o nome associado a Queue

Para saber mais utilize o man pages para obter mais informações sobre as Queues

Implementação

Para facilitar o uso desse mecanismo, o uso da API referente a Queue POSIX é feita através de uma abstração na forma de uma biblioteca.

posix_queue.h

Para determinar como o processo vai usar a Queue foi definido um enum que representa o modo que a Queue vai operar, seguido de uma estrutura que representa o contexto necessário para sua utilização.

Aqui é apresentada a API que abstrai as particularidades da API, facilitando seu uso.

posix_queue.c

Aqui em POSIX_Queue_Init, a estrutura referente aos atributos da queue é criada, e recebe os parâmetros providos pelo contexto, dependendo do modo em que a queue vai operar definirá a abertura do arquivo. Caso a inicialização da queue seja concluída com sucesso retornará true.

O envio da mensagem para a queue tem um ponto meio peculiar a mensagem deve ser menor que o valor estabelecido na sua configuração. Dessa forma é verificado se o tamanho da mensagem a ser enviada é menor que o valor atribuído na sua inicialização.

Na recepção da mensagem também existe uma peculiaridade, o buffer precisa ser maior que o configurado na sua inicialização, dessa forma é verificado o size do buffer utilizado por argumento versus o buffer do contexto.

Para remover a queue é utilizado seu id para ser fechada e o arquivo apagado

Para demonstrar o uso desse IPC, iremos utilizar o modelo Produtor/Consumidor, onde o processo Produtor(button_process) vai escrever seu estado interno no arquivo, e o Consumidor(led_process) vai ler o estado interno e vai aplicar o estado para si. Aplicação é composta por três executáveis sendo eles:

  • launch_processes – é responsável por lançar os processos button_process e led_process através da combinação fork e exec
  • button_interface – é responsável por ler o GPIO em modo de leitura da Raspberry Pi e escrever o estado interno no arquivo
  • led_interface – é responsável por ler do arquivo o estado interno do botão e aplicar em um GPIO configurado como saída

launch_processes

No main criamos duas variáveis para armazenar o PID do button_process e do led_process, e mais duas variáveis para armazenar o resultado caso o exec venha a falhar.

Em seguida criamos um processo clone, se processo clone for igual a 0, criamos um array de strings com o nome do programa que será usado pelo exec, em caso o exec retorne, o estado do retorno é capturado e será impresso no stdout e aborta a aplicação. Se o exec for executado com sucesso o programa button_process será carregado.

O mesmo procedimento é repetido novamente, porém com a intenção de carregar o led_process.

button_interface.h

Para usar a interface do botão precisa implementar essas duas callbacks para permitir o seu uso

A assinatura do uso da interface corresponde ao contexto do botão, que depende do modo selecionado, o contexo da Queue, e a interface do botão devidamente preenchida.

button_interface.c

A implementação da interface baseia-se em inicializar o botão, inicializar a Queue, e no loop realiza a mensagem para queue mediante o pressionamento do botão.

led_interface.h

Para realizar o uso da interface de LED é necessário preencher os callbacks que serão utilizados pela implementação da interface, sendo a inicialização e a função que altera o estado do LED.

A assinatura do uso da interface corresponde ao contexto do LED, que depende do modo selecionado, o contexo da Queue, e a interface do LED devidamente preenchida.

led_interface.c

A implementação da interface baseia-se em inicializar o LED, inicializar a Queue, e no loop realiza a leitura da mensagem

Compilando, Executando e Matando os processos

Para compilar e testar o projeto é necessário instalar a biblioteca de hardware necessária para resolver as dependências de configuração de GPIO da Raspberry Pi.

Compilando

Para faciliar a execução do exemplo, o exemplo proposto foi criado baseado em uma interface, onde é possível selecionar se usará o hardware da Raspberry Pi 3, ou se a interação com o exemplo vai ser através de input feito por FIFO e o output visualizado através de LOG.

Clonando o projeto

Pra obter uma cópia do projeto execute os comandos a seguir:

Selecionando o modo

Para selecionar o modo devemos passar para o cmake uma variável de ambiente chamada de ARCH, e pode-se passar os seguintes valores, PC ou RASPBERRY, para o caso de PC o exemplo terá sua interface preenchida com os sources presentes na pasta src/platform/pc, que permite a interação com o exemplo através de FIFO e LOG, caso seja RASPBERRY usará os GPIO’s descritos no artigo.

Modo PC

Modo RASPBERRY

Executando

Para executar a aplicação execute o processo launch_processes para lançar os processos button_process e led_process que foram determinados de acordo com o modo selecionado.

Uma vez executado podemos verificar se os processos estão rodando atráves do comando

O output

Interagindo com o exemplo

Dependendo do modo de compilação selecionado a interação com o exemplo acontece de forma diferente

MODO PC

Para o modo PC, precisamos abrir um terminal e monitorar os LOG’s

Dessa forma o terminal irá apresentar somente os LOG’s referente ao exemplo.

Para simular o botão, o processo em modo PC cria uma FIFO para permitir enviar comandos para a aplicação, dessa forma todas as vezes que for enviado o número 0 irá logar no terminal onde foi configurado para o monitoramento, segue o exemplo

Output do LOG quando enviado o comando algumas vezez

MODO RASPBERRY

Para o modo RASPBERRY a cada vez que o botão for pressionado irá alternar o estado do LED.

Matando os processos

Para matar os processos criados execute o script kill_process.sh

Conclusão

POSIX Queue é uma alternativa ao Queue System V, porém com a idéia de ser portável, porém a Queue System V permanece até os dias de hoje, devido a quantidade de aplicações criadas devido à esse recurso, o que ainda dá muita força no seu uso.

Referência

Outros artigos da série

<< Shared Memory System VPOSIX Semaphore >>

Engenheiro Elétrico de Formação mas é Engenheiro de Software de profissão, Pós Graduado em Sistemas Embarcados. Apaixonado por Idiomas, mas o idioma que mais lhe fascina é a Linguagem C.
Jogador de CTF, mas prefire Battlefield 1, exige menos da capacidade cognitiva :P. Atualmente atua como desenvolvedor de sistemas distribuídos no ramo aeronáutico. Quando está de bobeira fica desenhando personagens de Anime, criando conteúdo para o canal[Solidcris - Zerando Games] ou pedalando pela cidade de São Paulo.

Notificações
Notificar
guest
0 Comentários
Inline Feedbacks
View all comments

WEBINAR

Imagens de Ultrassom: Princípios e Aplicações

DATA: 26/10 ÀS 19:30 H