Rendimiento garantizado con pthread_cond_wait y pthread_cond_signal

Question

Suponiendo que tengo un programa en C con 3 hilos POSIX, que comparte una variable global, mutex y variable de condición, dos de los cuales están ejecutando el siguiente psuedocode:

...process data...
pthread_mutex_lock( &mutex );
variable = data_ptr;
pthread_cond_signal( &cond );
pthread_mutex_unlock( &mutex );

Y la tercera ejecución:

while(1) {
    while( variable == NULL ) {
        pthread_mutex_wait( &cond, &mutex );
    }
    printf( "Data is %d", *variable );
}

¿Es seguro asumir que el tercer hilo verá los datos de cada uno de los dos primeros?

Dicho de otra manera, si un hilo está esperando en un mutex y una variable de condición, es seguro asumir que será el próximo en obtener el bloqueo si se señala, en lugar de algún otro hilo que pueda ser esperando en la cerradura?

Answer 1

No hay tal cosa como pthread_mutex_wait. Supongo que quieres decir:

pthread_mutex_lock(&mutex);
/* ... */
while (1) {
  while (variable == NULL)
    pthread_cond_wait(&cond, &mutex);
  printf("Data is %d", *variable);
}
/* ... */
pthread_mutex_unlock(&mutex);

No hay garantía de que el tercer hilo verá los datos de ambos. pthread_cond_signal despertará el tercer hilo, pero puede que no tome el mutex de inmediato. Uno de los otros escritores puede tomar el mutex primero. Sin embargo, puede lograr lo que desea con un poco más de trabajo:

void put(int *p) {
  pthread_mutex_lock(&mutex);
  while (variable)
    pthread_cond_wait(&cond_empty, &mutex);
  variable = p;
  pthread_cond_signal(&cond_full);
  pthread_mutex_unlock(&mutex);
}

int *get() {
  int *ret;

  pthread_mutex_lock(&mutex);
  while (!variable)
    pthread_cond_wait(&cond_full, &mutex);
  ret = variable;
  variable = NULL;
  pthread_cond_signal(&cond_empty);
  pthread_mutex_unlock(&mutex);

  return ret;
}

Al esperar explícitamente la lectura de la variable, evitamos la posible condición de carrera.

Answer 2

Esto es lo que encontré en el estándar :

  

4.13 Política de programación

     

Una política de programación afecta el proceso o el orden de los hilos:

     

[...]

     

  
• Cuando un proceso o subproceso es un subproceso bloqueado y se convierte en un subproceso ejecutable
  

     

Las implementaciones conformes definirán la manera en que cada una de las políticas de programación puede modificar las prioridades o afectar el orden de los procesos o subprocesos en cada una de las situaciones mencionadas anteriormente. Además, las implementaciones conformes definirán en qué otras circunstancias y de qué manera cada política de programación puede modificar las prioridades o afectar el orden de los procesos o subprocesos.

Entonces aparentemente no está definido. No es sorprendente: en general, no se puede suponer nada sobre qué hilo ejecutable se programará para ejecutarse.

Answer 3

De acuerdo con la página de manual pthread_cond_wait

  

Los subprocesos que están desbloqueados deberán competir por el mutex de acuerdo con la política de programación (si corresponde), y como si cada uno hubiera llamado pthread_mutex_lock ().

Desafortunadamente, por lo que puedo decir, no hay una política de programación disponible que le brinde el comportamiento que desea.