2009-06-29 7 views
27

Al usar múltiples hilos, la memoria compartida debe ser bloqueada por secciones críticas. Sin embargo, el uso de secciones críticas causa bloqueos potenciales. ¿Cómo pueden evitarse?¿Cómo evitar interbloqueos?

+12

¿Por qué el voto a favor? Y más importante aún, ¿por qué se cierra esto? –

+2

hacer esta wiki de la comunidad - en este momento solo se ve como la agricultura de reputación –

+9

Hm. Me pareció una pregunta perfectamente válida, una que realmente me gustaría ver respondida. –

Respuesta

10

Una forma es utilizar una jerarquía de las secciones críticas. Si se asegura de que nunca se ingrese una sección crítica principal dentro de uno de sus elementos secundarios, no pueden producirse bloqueos. La dificultad es hacer cumplir esta jerarquía.

1

Debe codificar los programas multihilo con mucho cuidado. No hay atajos, debe comprender el flujo de su programa, de lo contrario estará condenado.

2

Cuando trabajo en C++, las siguientes obras para mí:

  1. todos los métodos públicos (excluyendo ctor y dtor) de una cerradura de clase multi-hilo

  2. métodos privados no pueden llamar a métodos públicos

No es un método general para evitar interbloqueos.

1

Puedes evitar cri secciones ticas usando el mensaje pasando el en su lugar (llamadas síncronas y asíncronas). Cuando usa llamadas síncronas, aún debe asegurarse de no hacer una llamada circular, en la que el subproceso A hace una pregunta a B, y B necesita hacer una pregunta para poder responder.

Otra opción es realizar llamadas asincrónicas en su lugar. Sin embargo, es más difícil obtener valores de retorno.

Nota: De hecho, un sistema de paso de mensajes se implementa mediante una sección crítica que bloquea la cola de llamadas, pero se abstrae.

1

Entre los diversos métodos para ingresar a secciones críticas, los semáforos y mutex son los más populares.

  • Un semáforo es un mecanismo de exclusión mutua de espera y es un mecanismo de bloqueo, así que el concepto es confuso para la mayoría, pero en fin, un hilo de activar un mutex sólo puede desactivarlo. Teniendo esto en cuenta...

  • No permita que ningún proceso bloquee un número parcial de recursos, si un proceso necesita 5 recursos, espere hasta que todos estén disponibles.

  • si usa semáforo aquí, puede desbloquear/desechar el recurso ocupado por otro hilo. con esto me refiero a la preferencia es otra razón.

Estas 2 según yo son las condiciones básicas, las 2 restantes de las 4 precauciones comunes pueden estar relacionadas con estas.

Si no está de acuerdo, añada comentarios. Ya llegué tarde, luego agregaré una explicación más clara y más clara.

0

ALGORITMO se utiliza el siguiente evitar un punto muerto:

algoritmo del banquero

-Impose condiciones menos estrictas que en la prevención de estancamiento en un intento de conseguir una mejor utilización de los recursos

estado -Safe

• El sistema operativo puede garantizar que todos los procesos actuales puedan completar su trabajo dentro de un tiempo finito

estado -Unsafe

• no implica que el sistema está en un punto muerto, pero que el sistema operativo no puede garantizar que todos los procesos actuales pueden completar su trabajo dentro de un tiempo finito

-Requiere que los recursos se asignen a procesa solo cuando las asignaciones resultan en estados seguros. -Tiene una serie de puntos débiles (como requerir un número fijo de procesos y recursos) que impiden que se implemente en sistemas reales

+1

Hola y bienvenido. Puede publicar una respuesta mejor al explicar más detalladamente lo que ha hecho. ¿Has usado el algoritmo? En que situación? ¿Por qué lo recomiendas en este caso? –

Cuestiones relacionadas