2012-02-24 24 views
8

Quiero aclaraciones sobre el mutex y el semáforo.
Mi pregunta es,¿Qué hace realmente mutex y semáforo?

  1. Lo que en realidad mutex hacer cuando un hilo intenta entrar en una región bloqueada por un mutex, a. espera a que se libere la cerradura? o b. se va a dormir hasta que se libere la cerradura. En ese caso, ¿cómo se despierta nuevamente cuando se libera la cerradura?
  2. La misma pregunta que 1, pero en este caso es semáforo.
  3. ¿Me puede dar algo de código con respecto espera ocupada en pthread en C, y también un caso en el que el hilo se va a dormir en vez de esperar? ¿dormir significa que está bloqueado o que dormir es otro tipo de espera ocupada?
  4. Quiero saber algunos programas donde se cubren estas situaciones, por ejemplo, algunos códigos fuente c donde se implementan la espera ocupada, el bloqueo, etc.
+0

¿Es esta tarea? –

+0

No, aprendí sobre la espera ocupada y los mecanismos de bloqueo para la sincronización de hilos. Pero no estoy seguro de lo que hace mutex y semáforo. –

Respuesta

5

Cuando un hilo intenta adquirir un bloqueo en un mutex , si ese mutex ya está retenido, normalmente utilizará una llamada al kernel del sistema operativo para indicar que está esperando, y luego, cuando el hilo que actualmente contiene el bloqueo desbloquee el mutex, se ejecutará una llamada al kernel del sistema operativo para reactivarlo. uno de los hilos de espera.

Lo mismo se aplica a un semáforo, excepto que sólo bloquea si el cómputo es reducido por debajo de cero, y procesos únicamente se despiertan cuando el recuento vuelve por encima de cero.

Una espera ocupada es donde no bloquear o sueño cuando la espera de algo, pero sondea repetidamente en un bucle, por lo que el procesador está siempre ocupado, pero no hacer nada útil.

Para lograr realmente una espera ocupada, necesita una variable atómica, pero los hilos POSIX no proporciona tal cosa, por lo que no se puede escribir realmente una espera ocupada en pthreads. Lo más cerca que puede obtener es bloquear un mutex, leer una bandera, desbloquear el mutex, bucle si no se configuró la bandera. Esto bloquea y desbloquea repetidamente el mutex, pero no espera a que los datos estén listos. En esta situación, debe usar una variable de condición en su lugar.

Normalmente, dices que un hilo está durmiendo si ha llamado a algo como usleep para suspender su propia ejecución durante un período de tiempo específico. Esto es opuesto al bloqueo, donde está esperando una señal específica que será proporcionada por otro hilo.

+0

"luego hará una llamada al kernel del sistema operativo para activar uno de los hilos de espera". , entonces significa que los hilos se ponen en reposo cuando se espera la liberación del mutex o la disminución del valor del semáforo? no se los mantiene esperando en el fondo durante un tiempo específico? –

+2

Cómo se maneja es un detalle de implementación del sistema operativo, pero sí, un hilo en espera no suele consumir ninguna CPU. Se agrega a una lista de hilos en espera por el sistema operativo, y solo se despierta cuando se indica mediante el mutex que se desbloquea. –

+0

Puede lograr ocupado esperando con pthreads, es por eso que hay las funciones pthread_spin_ {init, destroy, lock, unlock, trylock}. – janneb

-1

En simples palabras, es objeto mutex para las cosas cuando usted está preocupado con 1 cerradura .... semáforo es para múltiples cerraduras .. Voy a tratar de enviarle las muestras. Recuerdo que tenía algunas tareas relacionadas con la exclusión mutua y de semáforos en C .. En lo que se refiere a este concepto es algo gracioso aquí http://geekswithblogs.net/shahed/archive/2006/06/09/81268.aspx :)

Gracias

+0

semáforo también se puede utilizar para un solo bloqueo. –

0

Depende del tipo de mutex (su implementación de respaldo), algunos tienen spinning ocupado con retroceso, otros simplemente duermen el objeto de la rosca kernel que luego se despertará cuando el mutex se actualice y algunos sean híbridos de los dos (el motor Source de Valve usa los híbridos). Sus características también dependen de cuándo y con qué frecuencia debe cruzar las barreras kernel/espacio de usuario, ya que a veces puede ser más costoso que simplemente girar un poco más (ver this si quieres obtener más en el lado giratorio vs lado de dormir).

objetos mutex son generalmente para la entrada de un solo hilo a la vez (aunque pueden apoyar entrada recursiva por el mismo hilo).Los semáforos, por otro lado, permiten solo n subprocesos a la vez para intentar adquirirlo (consulte este artículo MSDN, o this informe comparativo de Intel).

Dormir un subproceso generalmente significa que renuncia a su cómputo de asignación timesize hasta que esté listo para ser despertado y el planificador del sistema operativo le da otro segmento de tiempo. los mejores ejemplos que probablemente encontrará en realidad estarían en el origen del kernel de Linux (o cualquier otro sistema operativo de código abierto para el caso).

+0

Hola, estoy particularmente interesado en la implementación de posix threads en Linux C. Entonces, desde un punto de vista posix, ¿qué mutex y semáforo realmente hacen? Por ejemplo, si escribo un código en C donde algunos datos compartidos están bloqueados con mutex, cuando otros hilos vienen a acceder, ¿esperará? o simplemente bloqueado la liberación de sus recursos? y qué sucederá en caso de semáforo. si el hilo se bloquea, ¿cómo se implementa la espera de hilado y ocupado en posix C? ¿Son las variables de condición la única forma? –

0
  1. Lo que en realidad mutex hacer cuando un hilo intenta entrar en una región bloqueada por un mutex, a. espera a que se libere la cerradura? o b. va a dormir hasta que se suelte la cerradura. En ese caso, ¿cómo se vuelve a activar cuando se libera la cerradura?

Cuando un hilo intenta adquirir un bloqueo de exclusión mutua, que se ha quedado atascado y devuelve sólo si el bloqueo se concede a ese hilo. El sistema operativo reconoce el bloqueo, por lo que el sistema operativo sabe que hasta que dicho bloqueo esté disponible para dar hilo, no tiene nada más que hacer. El hilo está estacionado dentro del sistema operativo. Solo el SO sabe que ahora el hilo tiene propiedad, vuelve a dormirse. En un solo sistema de CPU, en esa misma instancia, si otro proceso está activado, el bloqueo de exclusión mutua regresará solo cuando el hilo tenga ambos: ¡CPU disponible y bloqueo garantizado!

Nota: cuando lo haces fwrite o select sucede lo mismo. Como el sistema operativo sabe que el IO respectivo llevará tiempo, el hilo queda inactivo. Cuando llegan los datos, el hilo se vuelve ejecutable.

  1. Igual a la nota 1, pero en este caso se trata de semáforos. ¿Me puede dar algún código con respecto a la espera ocupada en pthread en C, y también un caso donde hilo se va a dormir en lugar de esperar? ¿dormir significa que está bloqueado o dormir es otro tipo de espera ocupada?

En ambos casos, NO hay una espera ocupada. Si alguien está ocupado esperando matar el tiempo hasta que consigas el bloqueo, ¡en realidad has fallado el propósito del bloqueo! Considere esto, digamos que tenemos una carcasa de CPU estrictamente única (y un sistema operativo estúpido). Entonces, lo que sucede es que el hilo 1 intenta adquirir el bloqueo, ya que el bloqueo se encuentra con el hilo B, por lo que el hilo A comienza a hacer esperar. Por lo tanto, la CPU nunca se libera del subproceso A y el subproceso B nunca tiene posibilidad de ejecución en la CPU; al final, ambos subprocesos están en una situación inútil. Locks no hace nada en el objeto thread. Pero el proceso de bloqueo invariablemente aparcar los hilos

+0

Hola, está bien, entonces quieres decir si hay algo de spinning necesario, tengo que implementar explícitamente esa espera ocupada, es decir, con algunas variables o variables de condición ¿no? Quiero decir mutex y semáforo no permite que los hilos esperen, ¿verdad? por ejemplo, si un semáforo se inicializa con 5, entonces cuando es 5, el sistema operativo pondrá en espera otros subprocesos hasta que el semáforo disminuya de 5, y luego los subprocesos serán reactivados por el sistema operativo, ¿estoy bien? –

+0

@Pbasak una vez que el subproceso obtiene acceso de mutex (o si se cumple la condición de semáforo), el subproceso ahora es 'ejecutable' - podría haber muchos subprocesos ejecutables en un sistema, por lo que depende de otros aspectos de la programación del sistema operativo. La adquisición de Mutex por sí sola no controla otros hilos en el sistema, pero su número ahora está en la cola activa. –

0

espera, durmiendo, el bloqueo, todos significan lo mismo:

  1. El hilo hace una llamada al sistema (obtener un mutex o semáforos, esperar algún tiempo, lo que sea)

  2. El sistema operativo toma el control, ejecuta el programador, marca el hilo como la espera de un recurso, actualiza el estado de otros hilos también, luego da control a un hilo que está listo para ejecutarse. Si hay más de un hilo listo para ejecutarse, uno se selecciona de acuerdo con la política de programación.

  3. Tan pronto como el recurso esté disponible (a través de otra llamada al sistema hecha por otro hilo), el planificador actualiza el estado del hilo anterior de esperar que un recurso esté listo para ejecutarse y el hilo se controla tan pronto como la política del planificador lo decide.

Mientras el hilo esté esperando un recurso, no consume CPU. No hay votación de su parte.

3

favor, eche un vistazo a: https://stackoverflow.com/a/24582076/3163691

Sí, tanto mutex y semáforo a sincronizar los objetos del núcleo, que cuando un hilo intenta adquirir uno de ellos, este hilo se pone a dormir si ese objeto ya es propiedad de otro hilo.

Como ya adivinado, este dormir es una característica crucial porque permite que otros hilos para hacer el trabajo más útil que acaba de 'bucle/de votación'.

El dormir de estos hilos termina cuando el hilo que posee el objeto liberación ella.

[OS Programador no da ninguna ejecución rebanada a hilos de dormir].

contraste con una cerradura & spinlock, donde un hilo está en un precioso tiempo de CPU perder estado de bucle/ocupado en espera 'hacer casi nada . Por lo tanto, se deben evitar spinlocks en el código de usuario. Utilice una sección crítica , mutex o semáforo en su lugar !.

Como puede ver en el enlace de arriba, ambos objetos son diferentes y deben usarse en el contexto correcto que se ajuste mejor.

Piense en un mutexcomo un bloqueoque permite simplemente un hilo ser la dueña. Y que tiene muchos atributos seguros (propiedad, notificación de terminación, recursión, etc.).

Y, pensar en un semáforocomo un bloqueoque permite simplemente un número determinado de hilos de sus dueños. Sin embargo, no tiene los muchos atributos útiles de mutex.

Espero que esto ayude.

Cuestiones relacionadas