Mutex en RTOS en esta situación específica

Navega tus respuestas
1

Considere los siguientes códigos: 

/*----------------------------------------------------------------------------
 First Thread 
 *---------------------------------------------------------------------------*/
void Thread1 (void const *argument) 
{
    for (;;) 
    {
        osMutexWait(mutex, osWaitForever); 
                Thread1_Functions;
        osMutexRelease(mutex);  
    }
}

/*----------------------------------------------------------------------------
  Second Thread  
 *---------------------------------------------------------------------------*/
void Thread2 (void const *argument) 
{
    for(;;)
    {
        osMutexWait(mutex, osWaitForever);
                Thread2_Functions;
        osMutexRelease(mutex);
    }
}

Por lo que he notado en la programación de RTOS, RTOS asigna un tiempo específico para cada tarea y una vez finalizado, cambia a la otra tarea. Luego, en este tiempo específico, dentro del bucle infinito de la tarea, tal vez el bucle se repita varias veces hasta que finalice el tiempo específico de la tarea. Supongamos que la tarea se termina en menos de la mitad del tiempo, luego tiene un tiempo para ejecutar esta tarea una vez más: en la última línea después de liberar mutex, entonces logrará mutex antes que task2 por segunda vez, ¿Soy cierto? supongamos que la marca del temporizador se produce cuando MCU ejecuta Thread1_Functions por segunda vez, luego task2 no puede ejecutarse debido a mutex propiedad de task1, RTOS ejecuta la tarea 1 de nuevo y si la marca del temporizador se produce cada vez en Thread1_Functions, la tarea 2 no tiene oportunidad de ejecutarse, ¿verdad?

    
pregunta Leo Rfk

1 respuesta

1

Esto depende de la implementación específica de RTOS. Existen varios esquemas de exclusión mutua y de planificación, por lo que una respuesta general es bastante difícil, ya que cualquier cosa podría suceder, por lo que podría ser correcto para un RTOS específico.

Esto es lo que esperaría:

  1. La tarea 1 bloquea el mutex
  2. La marca del sistema se produce y cambia a la Tarea 2
  3. La tarea 2 se ejecuta hasta que quiere bloquear la exclusión (ya bloqueada por la tarea 1)
  4. La tarea 2 se detiene, la tarea 1 tiene prioridad para ejecutarse hasta que libere el mutex
  5. La tarea 1 se ejecuta hasta que libera el mutex. Al liberarlo, el RTOS vuelve a la tarea 2
  6. La tarea 2 bloquea el mutex
  7. La marca del sistema se produce y cambia a la Tarea 1
  8. La tarea 1 se ejecuta hasta que quiere bloquear la exclusión (ya bloqueada por la tarea 2)
  9. La tarea 1 se detiene, la tarea 2 tiene prioridad para ejecutarse hasta que libere el mutex
  10. ... (Ya ves el patrón, con suerte)

Entonces, incluso entonces la tarea 2 se ejecutará eventualmente.

Si tiene que bloquear un mutex durante un tiempo tan largo como para que llegue a la región del tick del sistema, daría un paso atrás y pensaría en mi arquitectura y diseño de sistema y buscaría puntos en los que se pueda mejorar. .

Pero para estar seguro de lo que sucede, debe leer el manual del RTOS que está utilizando.

    
respondido por el Arsenal

Lea otras preguntas en las etiquetas

pregunta básica sobre la alimentación de un motor de CC Power In no es igual a Power Out