Digamos que tengo tres hilos que necesitan acceso a una colección y uso un bloque de bloqueo alrededor del acceso en cada hilo. Ocurre lo siguiente ...Bloquear instrucción C#
(1) Tema 1 obtiene la cerradura de la colección
(2) Tema 2 se bloquea
(3) Tema 3 se bloquea
Cuando Tema 1 libera el bloqueo, ¿Quién se lleva el candado después? ¿Es acceso FIFO?
Gracias
No debe cuidar que recibe el bloqueo al lado.
Suponiendo que es como Win32, la respuesta es que podría ser FIFO pero podría no serlo (debe ser algo más). Por ejemplo, un hilo de mayor prioridad debería ser el primero; pero los hilos pueden obtener un impulso temporal o disminuir su prioridad dependiendo de lo que han estado haciendo recientemente.
Según lo que he leído, esto es correcto. Se puede pensar que Lock es FIFO, pero no está garantizado. –
Su pregunta implica que usted está buscando un comportamiento FIFO? Entonces es posible que desee probar el código de Jakub Sloup:
Monitor/lock which remember order in C# to simulate FIFO
Como ya se ha mencionado en las otras respuestas no hay un orden garantizado los subprocesos en espera recibirá una cerradura.
Enlace roto, desafortunadamente. –
Como respuesta a su pregunta, todos los subprocesos reciben el monitor.pulse que luego se disputará quién se queda con el candado.
Creo que la gente de wintellect escribió un blog sobre cómo este comportamiento podría llevar a una situación injusta, pero no hay justicia en el monitor.
La respuesta es, por definición, indeterminada.
Puede extender eso para decir que * no puedo * importarme. Tal vez. – JMD
Me doy cuenta de que debo programar los hilos para que no me importe, solo me pregunto cuál es el mecanismo. –
http://msdn.microsoft.com/en-us/library/aa645740(VS.71).aspx#vcwlkthreadingtutorialexample4mutex "La velocidad y el sistema operativo de la máquina que ejecuta la muestra pueden afectar el orden de salida". –