Problema a Ser Resolvido

Sistemas embarcados frequentemente operam em ambientes com recursos escassos e múltiplas tarefas concorrentes, tornando a coordenação entre tarefas crítica para garantir a execução correta. Deadlock ocorre quando duas ou mais tarefas estão esperando indefinidamente por recursos que nunca serão liberados, devido a um ciclo de espera circular. Já a starvation ocorre quando uma tarefa de baixa prioridade é perpetuamente preterida, nunca tendo a chance de acessar os recursos que precisa.

Esses problemas são agravados em sistemas de tempo real, pois atrasos não planejados podem resultar em falhas catastróficas. Em contextos como o FreeRTOS, que utiliza escalonamento por prioridade, essas questões se tornam ainda mais relevantes. Entender as condições que causam esses problemas e aplicar padrões de projeto adequados é fundamental para evitar falhas imprevisíveis.

Estrutura do Padrão

Um dos exemplos clássicos usados para ilustrar deadlock é o problema dos Filósofos Glutões. Nele, cinco filósofos sentam-se à mesa, cada um com um garfo à sua direita e esquerda, e precisam de ambos para comer. Se todos pegam um garfo e esperam o outro, ninguém come — ocorre um deadlock.

No contexto do FreeRTOS, esse problema se manifesta quando tarefas compartilham múltiplos recursos (por exemplo, semáforos ou mutexes) e os bloqueiam em ordens diferentes. Bruce Douglass apresenta padrões como Simultaneous Locking, Ordered Locking e Priority Ceiling como soluções. Cada um quebra uma ou mais das quatro condições necessárias para o deadlock:

1. Exclusão mútua;
2. Posse e espera (hold and wait);
3. Não-preempção;
4. Espera circularReal-Time Design Patter….

Papéis de Colaboração (Collaboration Roles)

• Tarefas (Threads): Agentes ativos que requerem acesso a recursos compartilhados.
• Scheduler (Escalonador): Gerencia as prioridades das tarefas no FreeRTOS.
• Mutex/Semáforos: Controlam o acesso a recursos não-reentrantes.
• Shared Resource: Qualquer dado ou periférico que precise ser protegido.
• Task Control Block (TCB): Armazena estado, prioridade e contexto de cada tarefa.

Consequências

O impacto da ocorrência de deadlock e starvation em sistemas embarcados pode ser catastrófico. Quando tarefas ficam permanentemente bloqueadas, recursos permanecem indisponíveis e o sistema pode parar completamente ou deixar de responder dentro do prazo esperado — o que, em aplicações críticas, como controle industrial ou dispositivos médicos, pode gerar danos materiais ou colocar vidas em risco.

No caso do deadlock, a principal consequência é a paralisação do sistema, mesmo com o processador ativo. O scheduler do FreeRTOS pode continuar operando, mas as tarefas envolvidas no ciclo de espera nunca prosseguem. Já na starvation, embora o sistema permaneça funcional, uma ou mais tarefas de baixa prioridade jamais obtêm acesso aos recursos, resultando em degradação progressiva do desempenho ou falhas intermitentes difíceis de diagnosticar.

Outra consequência importante é a dificuldade de debug e validação de sistemas embarcados com problemas intermitentes de bloqueio. Tais problemas não são facilmente reproduzíveis, pois dependem da ordem de execução das tarefas, que pode variar conforme as condições de tempo real.

Além disso, starvation é frequentemente associada à inversão de prioridade, onde uma tarefa de alta prioridade fica bloqueada esperando uma de baixa prioridade liberar um recurso. Isso pode ser agravado em sistemas com escalonamento por prioridade fixa, como o FreeRTOS, a menos que sejam adotados mecanismos como o herdamento de prioridade (priority inheritance) ou teto de prioridade (priority ceiling).

Portanto, as consequências não são apenas técnicas — elas impactam diretamente os critérios de qualidade e confiabilidade do projeto.

Estratégias de Implementação

Prevenir deadlocks e starvation exige disciplina na coordenação do acesso a recursos e a aplicação de padrões de projeto consolidados. No contexto do FreeRTOS, onde tarefas operam em diferentes níveis de prioridade e disputam semáforos, mutexes ou filas, a implementação correta dos mecanismos de sincronização é essencial.

1. Evitando Deadlock com Ordenação de Locks

A estratégia mais direta para evitar deadlocks é padronizar a ordem de aquisição de recursos. Se todas as tarefas adquirirem os recursos sempre na mesma ordem (por exemplo, do recurso A para o B), a condição de espera circular é evitada. Este padrão é conhecido como Ordered Locking Pattern, amplamente discutido por Douglass em Real-Time Design Patter.

// Exemplo de ordenação de mutexes no FreeRTOS
void Task1(void *pvParameters) {
    for (;;) {
        xSemaphoreTake(mutexA, portMAX_DELAY);
        xSemaphoreTake(mutexB, portMAX_DELAY);

        // Região crítica usando os dois recursos

        xSemaphoreGive(mutexB);
        xSemaphoreGive(mutexA);
    }
}

Todas as tarefas devem respeitar a mesma ordem A -> B ao adquirir múltiplos recursos.

2. Evitando Starvation com Herdamento de Prioridade

Quando uma tarefa de alta prioridade espera por um mutex que está com uma tarefa de baixa prioridade, pode haver starvation por inversão de prioridade. O FreeRTOS possui mutexes com herança de prioridade (xSemaphoreCreateMutex) justamente para mitigar esse problema.

SemaphoreHandle_t xMutex;

void vSetup() {
    xMutex = xSemaphoreCreateMutex(); // já inclui herança de prioridade
}

Neste mecanismo, a tarefa de baixa prioridade “empresta” sua prioridade para igualar à da tarefa que está bloqueada, impedindo que tarefas intermediárias a impeçam de prosseguir e liberar o recurso.

3. Timeout e Deadlock Detectável

Adicionar timeouts ao uso de mutexes pode ajudar a identificar cenários de deadlock em tempo de execução. Embora não evite o problema, permite detectar que algo saiu do esperado.

if (xSemaphoreTake(mutexA, pdMS_TO_TICKS(100)) == pdFALSE) {
    // Erro: recurso não obtido — possível deadlock
    vHandleDeadlockError();
}

4. Solução Filósofos Glutões com Recurso Central

Um exemplo clássico é substituir os mutexes laterais por um recurso central ou um semáforo de contagem (counting semaphore), limitando o número máximo de filósofos que podem pegar os garfos ao mesmo tempo.

SemaphoreHandle_t semGarfos;

void vInit() {
    semGarfos = xSemaphoreCreateCounting(4, 4); // 5 filósofos, 4 permissões
}

void Filosofo(void *pvParameters) {
    for (;;) {
        pensar();

        xSemaphoreTake(semGarfos, portMAX_DELAY);
        xSemaphoreTake(garfoEsquerda, portMAX_DELAY);
        xSemaphoreTake(garfoDireita, portMAX_DELAY);

        comer();

        xSemaphoreGive(garfoDireita);
        xSemaphoreGive(garfoEsquerda);
        xSemaphoreGive(semGarfos);
    }
}

Esse padrão evita deadlock ao garantir que no máximo 4 filósofos estejam tentando pegar dois garfos, sempre sobrando ao menos um.

Padrões Relacionados

A prevenção eficaz de deadlocks e starvation não depende apenas da ordem ou da prioridade, mas também do uso inteligente de padrões complementares que podem ser combinados para diferentes necessidades de sincronização. Bruce Powel Douglass apresenta um conjunto de padrões especialmente aplicáveis a sistemas de tempo real como os que usam o FreeRTOS:

1. Guarded Call Pattern

Esse padrão garante que a chamada a um recurso protegido só ocorra quando sua condição estiver satisfeita, evitando bloqueios desnecessários. Ele frequentemente usa sinais (flags ou semáforos binários) para proteger regiões críticas, reduzindo a chance de deadlocks ao evitar bloqueios longos.

if (xSemaphoreTake(xRecurso, 0) == pdTRUE) {
    acessarRecurso();
    xSemaphoreGive(xRecurso);
} else {
    // Recurso indisponível, decide-se agir de outra forma
}

2. Simultaneous Locking Pattern

Este padrão representa um cenário onde múltiplos recursos são adquiridos simultaneamente — situação comum no problema dos Filósofos Glutões. A solução consiste em sempre adquirir todos os recursos de uma vez (por exemplo, usando semáforo de contagem ou buffers predefinidos), ou falhar imediatamente caso isso não seja possível, evitando a espera bloqueante.

bool lock_all() {
    if (xSemaphoreTake(mutexA, 0) == pdTRUE) {
        if (xSemaphoreTake(mutexB, 0) == pdTRUE) {
            return true;
        } else {
            xSemaphoreGive(mutexA);
        }
    }
    return false;
}

3. Priority Ceiling Pattern

Muito eficaz contra inversão de prioridade, esse padrão eleva a prioridade de uma tarefa sempre que ela adquire um recurso compartilhado, ao nível da mais alta prioridade possível que pode usar o recurso. Essa estratégia exige mais controle, mas evita inversões e starvation sem necessidade de herança dinâmica de prioridade.

O FreeRTOS não implementa esse padrão nativamente, mas ele pode ser simulado ajustando temporariamente a prioridade da tarefa:

void accessResource() {
    UBaseType_t oldPrio = uxTaskPriorityGet(NULL);
    vTaskPrioritySet(NULL, PRIORITY_CEILING);

    usarRecursoCompartilhado();

    vTaskPrioritySet(NULL, oldPrio);
}

4. Static Priority Pattern

Este padrão, também documentado por DouglassReal-Time Design Patter…, recomenda que os níveis de prioridade sejam cuidadosamente atribuídos e fixos durante a operação. Isso facilita a verificação de schedulability e evita condições dinâmicas imprevisíveis que podem agravar a starvation.

Modelo de Amostragem: O Problema dos Filósofos Glutões com FreeRTOS

Vamos aplicar os conceitos discutidos em um exemplo prático no FreeRTOS: uma simulação do problema dos Filósofos Glutões, ilustrando tanto o problema quanto a solução com semáforo de contagem — uma estratégia segura para evitar deadlock.

Configuração

• 5 tarefas representando os filósofos.
• Cada filósofo precisa pegar dois garfos (mutexes) para comer.
• Usa-se um Counting Semaphore com valor 4, limitando o número de filósofos com permissão para tentar pegar os garfos ao mesmo tempo.
• Cada garfo é um mutex (representando um recurso compartilhado).

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"

#define NUM_FILOSOFOS 5

SemaphoreHandle_t garfos[NUM_FILOSOFOS];
SemaphoreHandle_t semPermissao;

void pensar(int id) {
    printf("Filósofo %d está pensando...\n", id);
    vTaskDelay(pdMS_TO_TICKS(500 + id * 100));
}

void comer(int id) {
    printf("Filósofo %d está comendo!\n", id);
    vTaskDelay(pdMS_TO_TICKS(300));
}

void Filosofo(void *pvParameters) {
    int id = (int) pvParameters;
    int garfoEsquerda = id;
    int garfoDireita = (id + 1) % NUM_FILOSOFOS;

    for (;;) {
        pensar(id);

        // Espera por permissão para tentar pegar os dois garfos
        xSemaphoreTake(semPermissao, portMAX_DELAY);

        // Pega garfos (ordem fixa: esquerda depois direita)
        xSemaphoreTake(garfos[garfoEsquerda], portMAX_DELAY);
        xSemaphoreTake(garfos[garfoDireita], portMAX_DELAY);

        comer(id);

        // Libera garfos
        xSemaphoreGive(garfos[garfoDireita]);
        xSemaphoreGive(garfos[garfoEsquerda]);

        // Libera permissão
        xSemaphoreGive(semPermissao);
    }
}

void main_app() {
    semPermissao = xSemaphoreCreateCounting(NUM_FILOSOFOS - 1, NUM_FILOSOFOS - 1);

    for (int i = 0; i < NUM_FILOSOFOS; i++) {
        garfos[i] = xSemaphoreCreateMutex();
    }

    for (int i = 0; i < NUM_FILOSOFOS; i++) {
        char nome[16];
        sprintf(nome, "Filosofo%d", i);
        xTaskCreate(Filosofo, nome, configMINIMAL_STACK_SIZE, (void *)i, 1, NULL);
    }

    vTaskStartScheduler();
}

Resultado

Neste modelo, evitamos o deadlock limitando o número de filósofos que podem competir por garfos a quatro. Assim, sempre haverá ao menos um garfo disponível, quebrando a condição de espera circular. Ao mesmo tempo, garantimos fairness entre tarefas com prioridade igual, evitando starvation em função da ordem de execução.

Conclusão

Ao trazer os clássicos problemas da ciência da computação como o dos Filósofos Glutões para o contexto de sistemas embarcados com FreeRTOS, reforçamos a importância de padrões de projeto adequados para lidar com concorrência. Evitar deadlock e starvation é essencial para garantir sistemas previsíveis, seguros e eficientes. Estratégias como ordenação de locks, uso de semáforos de contagem, herança de prioridade e padrões como Guarded Call e Priority Ceiling devem fazer parte do repertório de todo engenheiro de firmware.

The post Problemas de Deadlock e Starvation em Sistemas Embarcados: O caso dos Filósofos Glutões no FreeRTOS first appeared on MCU & FPGA.

Para isso, três técnicas são amplamente utilizadas: mutex, semáforos e a suspensão do escalonador. Cada uma dessas abordagens tem seu melhor momento de aplicação e, se usada de maneira inadequada, pode levar a problemas de desempenho ou até mesmo a falhas difíceis de depurar. Neste artigo, exploraremos quando e como usar cada uma delas, incluindo exemplos práticos para facilitar a compreensão.

Mutex: Exclusão Mútua para Recursos Compartilhados

O mutex (mutual exclusion) é um mecanismo utilizado para garantir que apenas uma tarefa por vez tenha acesso a um recurso compartilhado. Ele funciona como um cadeado: a primeira tarefa que o adquire pode continuar a execução, enquanto as demais precisam aguardar sua liberação.

Quando Usar Mutex

• Quando há um recurso que não pode ser acessado simultaneamente por mais de uma tarefa.
• Para garantir consistência de dados ao modificar variáveis compartilhadas.
• Em sistemas operacionais com preempção habilitada, onde uma tarefa pode ser interrompida a qualquer momento.

Quando Evitar Mutex

• Quando há altíssima concorrência, pois as tarefas podem passar muito tempo bloqueadas, reduzindo o desempenho.
• Quando um recurso pode ser acessado de forma não exclusiva, ou seja, múltiplas tarefas podem lê-lo sem problemas.
• Quando há risco de deadlocks, onde múltiplas tarefas ficam bloqueadas esperando a liberação de mutexes que nunca ocorrerão.

Exemplo de Uso de Mutex no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xMutex;
int shared_resource = 0;

void Task1(void *pvParameters) {
    while(1) {
         if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                    shared_resource++;
                    printf("Task1: Recurso compartilhado = %d\n", shared_resource);
                    xSemaphoreGive(xMutex);
          }
          vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void Task2(void *pvParameters) {
    while(1) {
            if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                      shared_resource--;
                      printf("Task2: Recurso compartilhado = %d\n", shared_resource);
                      xSemaphoreGive(xMutex);
            }
           vTaskDelay(pdMS_TO_TICKS(500));
     }
}

int main() {
    xMutex = xSemaphoreCreateMutex();
    if (xMutex != NULL) {
            xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
            xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
            vTaskStartScheduler()
    }
    while(1);
}

Semáforos: Controle de Fluxo e Contagem de Recursos

Os semáforos são estruturas mais flexíveis que os mutexes e podem ser usados para diferentes propósitos. Eles operam com um contador interno, que pode permitir múltiplas tarefas acessando um mesmo recurso, dependendo da configuração.

Quando Usar Semáforos

• Para controlar múltiplas instâncias de um recurso compartilhado, como um conjunto de conexões disponíveis em um servidor.
• Para sincronizar tarefas, permitindo que uma aguarde a outra concluir uma operação antes de continuar.
• Em sistemas embarcados onde múltiplas tarefas precisam se comunicar sem causar bloqueios desnecessários.

Quando Evitar Semáforos

• Quando há necessidade de exclusão mútua. Um semáforo mal configurado pode permitir que múltiplas tarefas acessem um recurso crítico simultaneamente.
• Quando o código não foi planejado corretamente, podendo levar a inconsistências difíceis de depurar.
• Quando há possibilidade de inversão de prioridade, onde tarefas de baixa prioridade podem atrasar a execução de tarefas mais importantes.

Exemplo de Uso de Semáforo no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xSemaphore;
int shared_counter = 0;

void Task1(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter++;
            printf("Task1: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void Task2(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter--;
            printf("Task2: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xSemaphore = xSemaphoreCreateBinary();
    xSemaphoreGive(xSemaphore);
    if (xSemaphore != NULL) {
        xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
        xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
        vTaskStartScheduler();
    }
    while(1);
}

Suspensão do Escalonador: Controle Total com Custo Alto

A suspensão do escalonador (scheduler lock) é uma abordagem mais extrema, onde o sistema operacional pausa a troca de tarefas, garantindo que a tarefa em execução complete seu trabalho sem interrupções.

Quando Usar a Suspensão do Escalonador

• Quando uma operação crítica precisa ser executada em um curto período de tempo e não pode ser interrompida.
• Para seções de código extremamente curtas e atômicas, onde o impacto da suspensão do escalonador é mínimo.
• Em sistemas bare-metal sem suporte a mutexes ou semáforos.

Quando Evitar a Suspensão do Escalonador

• Quando há tarefas de tempo real que precisam responder rapidamente a eventos externos.
• Se o código protegido for muito longo, pois a suspensão prolongada do escalonador pode causar degradação significativa no desempenho do sistema.
• Em sistemas onde múltiplas CPUs são usadas, pois suspender o escalonador em um núcleo não impede que outros núcleos executem tarefas concorrentes.

Exemplo de Suspensão do Escalonador no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

void CriticalTask(void *pvParameters) {
    while(1) {
        vTaskSuspendAll(); // Suspende o escalonador
        // Código crítico
        printf("Executando tarefa crítica\n");
        xTaskResumeAll(); // Retoma o escalonador
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xTaskCreate(CriticalTask, "Critical Task", 128, NULL, 1, NULL);
    vTaskStartScheduler();
    while(1);
}

Abordagem para Dispositivos I2C e SPI

Os protocolos de comunicação como I2C e SPI são amplamente utilizados em sistemas embarcados para comunicação entre microcontroladores e periféricos. A abordagem correta para controle de concorrência depende do tipo de comunicação e do contexto de uso.

I2C com Mutex no STM32F411RE

O protocolo I2C é um barramento compartilhado onde múltiplos dispositivos podem estar conectados ao mesmo controlador. Como apenas um dispositivo pode realizar a comunicação por vez, o uso de mutex é essencial para evitar colisões entre tarefas concorrentes que tentam acessar o barramento ao mesmo tempo.

#include "stm32f4xx_hal.h"
#include "FreeRTOS.h"
#include "semphr.h"

I2C_HandleTypeDef hi2c1;
SemaphoreHandle_t i2cMutex;

void I2C_Write(uint16_t devAddress, uint8_t *data, uint16_t size) {
    if (xSemaphoreTake(i2cMutex, portMAX_DELAY)) {
        HAL_I2C_Master_Transmit(&hi2c1, devAddress, data, size, HAL_MAX_DELAY);
        xSemaphoreGive(i2cMutex);
    }
}

SPI com Mutex no STM32F411RE

O protocolo SPI geralmente é mais rápido que o I2C, mas também pode sofrer de concorrência quando múltiplas tarefas tentam acessá-lo simultaneamente. O uso de mutex impede que duas tarefas interfiram uma na outra enquanto utilizam o barramento SPI.

#include "stm32f4xx_hal.h"
#include "FreeRTOS.h"
#include "semphr.h"

SPI_HandleTypeDef hspi1;
SemaphoreHandle_t spiMutex;

void SPI_Write(uint8_t *data, uint16_t size) {
    if (xSemaphoreTake(spiMutex, portMAX_DELAY)) {
        HAL_SPI_Transmit(&hspi1, data, size, HAL_MAX_DELAY);
        xSemaphoreGive(spiMutex);
    }
}

Melhor Abordagem

• I2C: Como é um barramento compartilhado entre múltiplos dispositivos, usar um mutex é essencial para evitar colisões.
• SPI: Em ambientes multitarefa, o uso de mutex também é recomendado para evitar que diferentes tarefas tentem acessar o mesmo barramento ao mesmo tempo.
• Semáforos podem ser usados para sincronizar eventos, como a recepção de dados em interrupções.

Essas práticas garantem que a comunicação com dispositivos externos ocorra de maneira segura e eficiente, sem causar falhas no sistema.

Conclusão

Escolher a técnica correta para o controle de concorrência é essencial para garantir a estabilidade e o desempenho de sistemas multitarefa. Como visto ao longo deste artigo:

• Mutexes são ideais para garantir exclusão mútua, prevenindo que múltiplas tarefas modifiquem simultaneamente um mesmo recurso compartilhado.
• Semáforos são úteis tanto para controle de múltiplas instâncias de um recurso quanto para sincronização de tarefas.
• A suspensão do escalonador deve ser usada com cuidado, sendo útil apenas em situações críticas onde uma interrupção durante a execução pode causar problemas graves.

Quando se trata de dispositivos como I2C e SPI, a escolha de mutexes para proteger o barramento e garantir a integridade da comunicação é a abordagem mais recomendada, enquanto semáforos podem ser úteis para coordenar eventos assíncronos.

Entender essas técnicas e aplicá-las corretamente resulta em sistemas mais eficientes, confiáveis e fáceis de manter. O uso adequado de mutexes, semáforos e a suspensão do escalonador garante que aplicações multitarefa operem de maneira fluida, sem impactos negativos na performance do sistema.

Com isso, esperamos que este artigo tenha esclarecido as principais diferenças entre essas abordagens e ajudado a tomar decisões mais informadas no desenvolvimento de sistemas embarcados e aplicações multitarefa.

The post first appeared on MCU & FPGA.

Neste artigo, vamos explorar os seguintes pontos:

1. O problema da exclusão mútua.
2. Como o algoritmo de Peterson resolve este problema.
3. A relação entre Peterson’s Algorithm e spinlocks.
4. Comparação com outras soluções de exclusão mútua.
5. Exemplos práticos em código.

1. O Problema da Exclusão Mútua

Em sistemas com threads ou processos que compartilham recursos (como variáveis ou arquivos), pode ocorrer o problema de condições de corrida. Isso ocorre quando dois ou mais processos tentam acessar e modificar o mesmo recurso ao mesmo tempo, causando resultados imprevisíveis.

A exclusão mútua garante que apenas um processo possa acessar o recurso crítico por vez.

2. O Algoritmo de Peterson

O algoritmo de Peterson é uma solução de exclusão mútua projetada para dois processos. Ele usa duas variáveis:

• flag[i]: indica que o processo i quer entrar na seção crítica.
• turn: determina de quem é a vez de entrar na seção crítica.

O algoritmo funciona da seguinte forma para dois processos (P0 e P1):

Implementação do Algoritmo

#include <stdio.h>
#include <pthread.h>
#include <stdbool.h>
#include <unistd.h>

#define NUM_ITERATIONS 5

bool flag[2] = {false, false};
int turn = 0;

void *process_0(void *arg) {
    for (int i = 0; i < NUM_ITERATIONS; i++) {
        // Indica interesse em entrar na seção crítica
        flag[0] = true;
        turn = 1;

        // Aguarda até que o outro processo não esteja interessado ou seja sua vez
        while (flag[1] && turn == 1);

        // Seção crítica
        printf("Processo 0 na seção crítica.\n");
        sleep(1);

        // Sai da seção crítica
        flag[0] = false;
    }
    return NULL;
}

void *process_1(void *arg) {
    for (int i = 0; i < NUM_ITERATIONS; i++) {
        // Indica interesse em entrar na seção crítica
        flag[1] = true;
        turn = 0;

        // Aguarda até que o outro processo não esteja interessado ou seja sua vez
        while (flag[0] && turn == 0);

        // Seção crítica
        printf("Processo 1 na seção crítica.\n");
        sleep(1);

        // Sai da seção crítica
        flag[1] = false;
    }
    return NULL;
}

int main() {
    pthread_t t0, t1;

    pthread_create(&t0, NULL, process_0, NULL);
    pthread_create(&t1, NULL, process_1, NULL);

    pthread_join(t0, NULL);
    pthread_join(t1, NULL);

    return 0;
}

3. Relação com Spinlocks

Peterson’s Algorithm pode ser visto como uma forma rudimentar de spinlock, uma técnica onde um processo “gira” em um loop verificando continuamente se pode acessar um recurso.

Vantagens e Desvantagens

• Vantagens:
  • Simples e eficiente para dois processos.
  • Não requer instruções atômicas específicas do hardware.
• Desvantagens:
  • Não é escalável para mais de dois processos.
  • É menos eficiente que soluções modernas que usam instruções como compare-and-swap.

Spinlock Clássico em C

#include <stdatomic.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

atomic_flag lock = ATOMIC_FLAG_INIT;

void lock_spin() {
    while (atomic_flag_test_and_set(&lock)); // Gira até obter o lock
}

void unlock_spin() {
    atomic_flag_clear(&lock); // Libera o lock
}

void *critical_section(void *arg) {
    lock_spin();
    printf("Thread %ld na seção crítica.\n", (long)arg);
    sleep(1);
    unlock_spin();
    return NULL;
}

int main() {
    pthread_t threads[2];

    for (long i = 0; i < 2; i++) {
        pthread_create(&threads[i], NULL, critical_section, (void *)i);
    }

    for (int i = 0; i < 2; i++) {
        pthread_join(threads[i], NULL);
    }

    return 0;
}

4. Comparação com Outras Soluções

5. Exemplos de Uso no Mundo Real

Embora Peterson’s Algorithm seja de interesse mais acadêmico, a ideia de exclusão mútua se aplica amplamente:

• Mutexes e Semáforos em sistemas operacionais.
• Controle de acesso em bases de dados.
• Exclusão mútua em drivers de hardware.

Conclusão

Peterson’s Algorithm é uma solução elegante para exclusão mútua, especialmente em cenários simples. Apesar de suas limitações, sua compreensão é essencial para qualquer profissional interessado em sistemas concorrentes.

The post Peterson’s Algorithm: Uma Solução Elegante para Exclusão Mútua first appeared on MCU & FPGA.