¿Se puede realizar el cambio de contexto en una sección crítica?

Question

Hace poco leí un blog interesante comparar mutex y semáforo:
"
http://www.feabhas.com/blog/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semaphores/
"

Cita de ella:
"
Si un cambio de contexto ocurre mientras que la tarea está en la región crítica, y otra tarea también llama a P (S), luego esa segunda tarea (y cualquier tarea posterior) será bloqueada para que no ingrese a la región crítica al ser puesta en estado de espera por el sistema operativo. En un momento posterior, la primera tarea se reprograma y llama a V (S) para indicar que ha salido de la región crítica. La segunda tarea ahora será acceso permitido a la región crítica. "

Si esto es cierto para semáforo, ¿también es cierto para mutex? No creo que sea cierto como si un bloque de código está bloqueado, debe ser" atómico "que no se puede cambiar de contexto o interrumpir . Estoy en lo cierto?

Answer 1

no, un conmutador de contexto puede ocurrir casi en cualquier parte. Mientras que es generalmente una buena idea para mantener bloqueos para un tiempo tan breve como sea posible, usted no querría todo el PC para bloquear sólo porque un proceso tenido tantos procesos mantengan bloqueos, ya que hay núcleos, esperando a que pase algo, ¿verdad?

el punto de un bloqueo es evitar que el código que podría interferir con el código en la cerradura de ser ejecutado - No es para detener el se está ejecutando otro código en cada proceso en el sistema. (Un cambio de contexto a un proceso diferente sigue siendo un cambio de contexto, después de todo.)

Answer 2

Depende de qué versión de una "sección crítica" esté tratando. Solo por ejemplo, en OS/2 (el predecesor de la versión actual de Windows que incluía secciones críticas por primera vez) el ingreso de una sección crítica impedía cambiar a una secuencia diferente en el mismo proceso. En Windows NT, cambiaron eso para que se permita la conmutación de subprocesos, por lo que otros subprocesos solo se bloquearán cuando/si intentan ingresar a la misma sección crítica.

En ambos casos, una sección crítica es local para un proceso, por lo que una secuencia en un proceso diferente nunca puede intentar ingresar a la misma sección crítica.

En otros sistemas, tendrá que ver cómo se especifica una sección crítica (suponiendo que tenga una) para saber lo que permite/prohíbe. No hay una definición universal.

Answer 3

Un cambio de contexto siempre es posible en Linux, no se puede monopolizar la CPU, pero los hilos que fallan al adquirir el bloqueo se bloquearán y el planificador no los seleccionará hasta que el bloqueo vuelva a estar disponible.

Prueba:
Ejecute este código y verá la salida desde entonces desde g y desde f nuevamente.

#include <stdio.h> 
#include <pthread.h> 
#include <semaphore.h> 

int global=0; 
sem_t sem; 
void* f(void *a){ 
    sem_wait(&sem); 
    printf("Inside a critical section: %d\n",global++); 
    ++global; 
    sem_post(&sem); 
    return a ; 
} 

void* g(void *a){ 
    printf("Function call to g.\n"); 
    return a ; 
} 

int main(void){ 
    pthread_t tids[10]; 
    sem_init(&sem, 0, 1); 
    int i; 
    pthread_t new_thread; 
    for (i=0; i < 10 ; ++i){ 
    if (i == 8) 
     pthread_create(&new_thread, NULL, g, NULL); 
    pthread_create(&tids[i], NULL, f, NULL); 
    } 
    for (i=0; i < 10 ; ++i){ 
    pthread_join(tids[i], NULL); 
    } 
    pthread_join(new_thread, NULL); 
} 

Answer 4

La mayor parte del tiempo, un hilo o proceso se puede conectar a cabo por el planificador cualquier momento, aún se encuentra en sección crítica. La sección crítica es solo una parte especial del código que no debe compartirse para ser ejecutada por otro hilo. Esto no es acceso atómico. Solo el semáforo o mutex es un acceso atómico. Si desea que la ejecución de código de sección crítica sea atómica, solo un hilo puede ejecutar estos códigos incluso en SMP, puede usar spinlock con interrupción deshabilitada. Si la interrupción está deshabilitada en un procesador, el programador deja de funcionar, no se ejecuta. Solo el código de ejecución de subprocesos en la sección crítica hasta que el subproceso libere el spinlock.Esta es la protección de código más alta que solo se usa en kernel, porque el conflicto entre la interrupción y el hilo del kernel solo ocurre en kernel. Por ejemplo, un isr recibe datos del dispositivo y un hilo del kernel lee estos datos. Luego funciona el spinlock.