Muy pronto, del 29 al 30 de noviembre en San Petersburgo y del 6 al 7 de diciembre en Moscú , lanzaremos el sexto seminario .NET . Esta vez sobre el tema de multihilo y competitividad. Ya escribimos sobre esto un par de veces en Habré, pero hoy hay una razón separada para esto: el seminario es una verdadera exclusión . Se describirá el funcionamiento de la primitiva de sincronización híbrida: Monitor . Sí, la pequeña cosa familiar es digna de un informe separado. Después de todo, en su trabajo tiene en cuenta tanto la frecuencia del procesador como el número de núcleos, tiene en cuenta el bloqueo de convoy / inanición y, en general, es muy complicado.
Y al final del artículo de entretenimiento, propondré pasar por un par de EXAMENES sobre subprocesos múltiples.
Un pequeño escenario del taller.
Lo más importante que proviene del sistema operativo es la programación de subprocesos. Después de todo, pueden trabajar en paralelo entre sí (cuando se están ejecutando actualmente en diferentes núcleos), y más a menudo (si estamos hablando de los mismos hilos) de forma secuencial. Después de todo, el sistema operativo no le da mucho tiempo a la ejecución, a todos, después de lo cual le da tiempo a los demás. El segundo, para este segmento, un cuanto, se puede asignar una cantidad de tiempo diferente. Por ejemplo, dependiendo de la versión del sistema operativo que estemos usando: servidor o usuario, si el subproceso de la interfaz de usuario es un subproceso de proceso con la ventana activa actual. En tercer lugar, hay prioridades y el concepto de "desplazar la multitarea", cuando su flujo, solo después de haber recibido el tesoro atesorado, puede perderlo, porque Se formó otro hilo con mayor prioridad. Resulta que nuestra aplicación depende en gran medida del entorno en el que funciona. Por ejemplo, algunos servicios de cálculo se sentirán mejor en la versión del servidor del sistema operativo (o con la configuración de rendimiento adecuada) cuando no haya otros servicios en la máquina: los cuantos serán largos, habrá mucho tiempo cuántico.
Pero aquí surge otra pregunta: si nuestro hilo en esta configuración establece un bloqueo a nivel del núcleo (por ejemplo, Semaphore (1)), el segundo hilo llega al bloqueo y entra en este bloqueo, entonces permanecerá en el sistema operativo del servidor mucho más tiempo de lo que estaba Estaría en la costumbre. Por qué Sí, porque el intervalo de tiempo del servidor es 6 veces más largo que el del cliente, y este subproceso primero tendrá que esperar hasta que el primer flujo llegue al punto de liberación del bloqueo, y luego cuando obtenga un nuevo cuanto.
Sin embargo, hay ayuda para tal caso: cuando se libera el bloqueo, todos los subprocesos que lo esperaban temporalmente (en 1 cantidad) tienen prioridad sobre otros subprocesos y el segundo subproceso recibirá tiempo de procesador inmediatamente.
CLRium 6
Estos tres párrafos son un 5% conciso del cuarto informe. Y ya es rico en información que se puede utilizar en todos los niveles: desde trabajar con primitivas de sincronización hasta trabajar con bibliotecas de alto nivel. Y nuestro programa es este:
- Veremos los tipos de procesos. Hay muchos de ellos, y usamos dos de ellos: son ordinarios y ModernApp;
- Tres informes seguidos son subprocesos de nivel de sistema operativo: programación en sistemas de núcleo único, núcleos múltiples y sistemas NUMA. En todas partes las reglas son diferentes y esto debe tenerse en cuenta en su trabajo;
- Análisis del trabajo de las primitivas de sincronización a nivel de tiempo cuántico. Todos aprendieron a hablar sobre lock / Mutex / Semaphore en entrevistas. No tiene sentido repetir, y por lo tanto nos armaremos con líneas de tiempo y veremos cómo se distribuyen los cuantos entre los procesadores en todas las primitivas de sincronización: Kernel-Space, User-Space e híbridas.
- Un verdadero taller exclusivo: la estructura del
Monitor primitivo. El hecho de que lock(){} revela en try { } finally { } que ya sabías sin mí, pero lo que Monitor.Enter , Monitor.Leave , Monitor.TryEnter . Monitor.TryEnter se Monitor.TryEnter es un tema para un infierno de informe completo, denso y separado. Créeme, todo dentro de él es muy, muy genial. Esta es una primitiva de sincronización híbrida que está construida para evitar el hambre, el bloqueo excesivo y el escape de convoyes de bloqueo. - Hasta tres informes sólidos sobre bloqueo y espera, incluido el ejemplo de aviones no tripulados de reconocimiento y defensa aérea, tratando de derribar estos aviones no tripulados. Y estos informes fueron tan apreciados por HighLoad ++ que fueron llamados a HighLoad ++ en Moscú el 07-08 de noviembre .
- Una serie de informes sobre PLINQ y Async-Await. Todo es lo más detallado posible. No por el reloj: estas cosas son suficientes en Internet. Cada tecnología se contará "desde adentro": como es habitual en CLRium.
- Y el seminario se cerrará con dos informes sobre la biblioteca de colecciones sin bloqueo de Microsoft e Intrinsics (instrucciones vectoriales para la paralelización a nivel de procesador).
Algunas estadísticas
Somos el seminario más grande del país y, en general, no somos una conferencia solo porque nos gusta nuestro formato. No elige entre los informes a los que no irá. Tú vas por todo. Además, comprende de antemano que todos los temas del seminario son de su interés, porque El tema es uno. Otro récord se establecerá en CLRium 6: 700 personas estarán presentes en ambas ciudades. Alrededor de 700 personas bombean sus habilidades en paralelo y trabajan con competencia. E irán a entrevistas. Ven y tú a nosotros :).