POSIX Shared Memory

Esse é o 20º artigo da série Comunicação entre procecessos. Nesse artigo é demonstrado o uso do POSIX Shared Memory

Introdução

POSIX Shared Memory é uma padronização desse recurso para que fosse altamente portável entre os sistemas. Não difere tanto da Shared Memory System V, porém utiliza uma forma de implementação totalmente nova(não abordado nesse artigo). Diferente dos outros mecanismos(Semaphore e Queue) necessita de outro recurso para que a memória alocada seja compartilhada entre os outros processos.

Systemcalls

Para utilizar a API referente a Shared Memory é necessário realizar a linkagem com a biblioteca rt.

Esta função cria ou obtém uma Shared Memory

Esta função remove uma Shared Memory criada pela shm_open

Implementação

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

posix_shm.h

Para o seu uso é criada uma enumeração que determina o modo de abertura dessa shared memory e uma estrutura que vai realizar a configuração dessa shared memory, como seu nome, tamanho e o modo de operação.

As funções pertinentes para criar e remover a shared memory

posix_shm.c

Aqui em POSIX_SHM_Init criamos a shared memory baseada no nome e seu handle é guardado. A shared memory não possui um mecanismo próprio como a Shared Memory System V, para isso ser possível é necessário o uso do mmap para que a shared memory seja visível por outros processos.

Aqui em POSIX_SHM_Cleanup é realizada a remoção da shared memory baseado no seu handle:

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.c

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 Shared Memory, 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 Shared Memory, e no loop alterar o conteúdo da shared memory 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 Shared Memory, e a interface do LED devidamente preenchida.

led_interface.c

A implementação da interface baseia-se em inicializar o LED, inicializar a Shared Memory, e no loop verifica se houve alteração no conteúdo da shared memory para poder alterar o seu estado interno.

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 Shared Memory permite que dois processos não relacionados se comuniquem compartilhando uma região de memória, de forma similar a Shared Memory System V, porém realiza esse procedimento através de mmap que não é relacionada a sua API igual aos outros mecanismos. Normalmente é usada em conjunto com o POSIX Semaphore.

Referência

Outros artigos da série

<< POSIX SemaphoreD-Bus >>

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