c# - que - Implementación interna de Lock(Monitor) en.NET

synchronized c#

Question

Para dominar alguna tecnología, debes saber cómo se hace en un nivel de abstracción más bajo. En el caso de la programación multiproceso, será bueno conocer las primitivas de sincronización.
Aquí está la pregunta, ¿cómo se implementó Lock (Monitor) en .NET?

Estoy interesado en tales puntos:
- ¿Utiliza los objetos del sistema operativo?
- ¿Requiere modo de usuario o modo kernel ?;
- ¿Qué es sobrecarga para los hilos que están esperando el bloqueo?
- ¿En qué casos se pueden violar los hilos que esperan por el bloqueo?

Actualizado:
"Si hay más de un hilo que contenga el bloqueo, se ponen en cola en una" cola lista "y se le otorga el bloqueo por orden de llegada. Nota: los matices en el comportamiento de Windows y el CLR significan que la imparcialidad de la cola a veces puede ser violada. "[C # 4.0 en una cáscara de nuez, Joseph Albahari] Así que esto es lo que estoy preguntando en la última pregunta sobre ''cola violada''.

Answer 1

Después de algunas investigaciones, he encontrado respuestas a mis preguntas. En general, CodeInChaos y Henk Holterman tenían razón, pero aquí hay algunos detalles.

Cuando el subproceso comienza a competir por un bloqueo con otros subprocesos, en primer lugar gira el bucle de espera durante un tiempo intentando obtener el bloqueo. Todas estas acciones se realizan en modo de usuario . Luego, si no hay éxito, el objeto del kernel del sistema operativo crea el Event , el hilo se cambia al modo kernel y espera la señal de este Event .

Así que la respuesta a mis preguntas es:
1. En el mejor de los casos, no, pero en el peor sí (el objeto de Event crea perezosamente si es necesario);
2. En general, funciona en modo de usuario, pero si los hilos compiten por un bloqueo demasiado largo, el hilo podría cambiarse a modo kernel (a través de la llamada de función no gestionada API Win);
3. Overhead para cambiar del modo de usuario al modo kernel (~ 1000 ciclos de CPU);
4. Microsoft afirma que es un algoritmo "honesto" como FIFO, pero no lo garantiza. (Por ejemplo, si el hilo de ''cola en espera'' se suspenderá, se moverá al final de la cola cuando se reanudará).

Answer 2

El artículo de Wikipedia tiene una descripción bastante buena de lo que es un "Monitor", así como su tecnología subyacente, la variable de condición.

Tenga en cuenta que el .NET Monitor es una implementación correcta de una variable de condición; la mayoría de las implementaciones publicadas de Win32 de CV son incorrectas, incluso las que se encuentran en fuentes normalmente acreditadas como el Dr. Dobbs. Esto se debe a que no se puede crear fácilmente un CV a partir de las primitivas de sincronización de Win32 existentes .

En lugar de simplemente crear un contenedor superficial (e incorrecto) sobre las primitivas de Win32, la implementación de .NET CV aprovecha el hecho de que está en la plataforma .NET, implementando sus propias colas de espera, etc.