Muito em breve, de 29 a 30 de novembro em São Petersburgo e de 6 a 7 de dezembro em Moscou , lançaremos o sexto seminário .NET . Desta vez, sobre o tema multithreading e competitividade. Já escrevemos sobre isso algumas vezes em Habré, mas hoje há uma razão separada para isso: o seminário é realmente exclusivo . A operação da primitiva de sincronização híbrida será descrita: Monitor
. Sim, a pequena coisa familiar é digna de um relatório separado. Afinal, em seu trabalho, ele leva em consideração a freqüência do processador e o número de núcleos, leva em consideração o comboio de bloqueio / a fome e, em geral, é muito complicado.
E no final do artigo sobre entretenimento, proponho passar por alguns QUIZs sobre multithreading.

Um pequeno cenário do workshop
A coisa mais importante que vem do sistema operacional é o agendamento de threads. Afinal, eles podem trabalhar em paralelo um com o outro (quando atualmente estão sendo executados em núcleos diferentes) e com mais frequência (se estamos falando sobre os mesmos threads) - sequencialmente. Afinal, o sistema operacional não dá muito tempo para a execução - para todos, após o que dá tempo para os outros. A segunda - para esse segmento - um quantum - pode ser alocada uma quantidade diferente de tempo. Por exemplo, dependendo da versão do sistema operacional em uso: servidor ou usuário, se o encadeamento da interface do usuário é um encadeamento do processo com a janela ativa atual. Em terceiro lugar, existem prioridades e o conceito de “multitarefa”, quando seu fluxo, depois de receber o quantum estimado, pode perdê-lo, porque outro segmento com uma prioridade mais alta formado. Acontece que nosso aplicativo é altamente dependente do ambiente em que trabalha. Por exemplo, algum serviço de cálculo se sentirá melhor na versão do servidor do sistema operacional (ou com as configurações de desempenho apropriadas) quando não houver outros serviços na máquina: os quanta serão longos, haverá muito tempo quântico.
Mas aqui surge outra questão: se o nosso encadeamento nesta configuração estabelecer um bloqueio no nível do kernel (por exemplo, Semaphore (1)), o segundo encadeamento entra no bloqueio e entra nesse bloqueio, então ele permanece no sistema operacional do servidor por muito mais tempo do que estava. estaria no costume. Porque Sim, porque o intervalo de tempo do servidor é 6 vezes maior que o do cliente, e esse encadeamento terá que aguardar até que o primeiro fluxo atinja o ponto de liberação do bloqueio e, em seguida, quando receber um novo quantum.
No entanto, existe ajuda para esse caso: quando o bloqueio é liberado, todos os threads que o esperavam temporariamente (em 1 quantum) têm prioridade sobre outros threads e o segundo thread receberá o tempo do processador imediatamente.
CLRium 6
Esses três parágrafos representam 5% concisos do quarto relatório. E ele já é rico em informações que podem ser usadas em todos os níveis: do trabalho com primitivas de sincronização ao trabalho com bibliotecas de alto nível. E nosso programa é este:
- Veremos os tipos de processos. Existem muitos deles, e usamos dois deles por força: estes são comuns e o ModernApp;
- Três relatórios consecutivos são encadeamentos no nível do sistema operacional: agendamento em sistemas de núcleo único, multinúcleo e sistemas NUMA. Em todo lugar, as regras são diferentes e isso deve ser levado em consideração no seu trabalho;
- Análise do trabalho de primitivas de sincronização no nível de tempo quântico. Todos vocês aprenderam a falar sobre bloqueio / Mutex / Semáforo em entrevistas. Não há sentido em repetir, e, portanto, nos armaremos com cronogramas e veremos como os quanta são distribuídos entre os processadores em todas as primitivas de sincronização: Kernel-Space, User-Space e híbridas.
- Um verdadeiro workshop exclusivo: a estrutura da primitiva
Monitor
. O fato de lock(){}
revelado na try { } finally { }
você já sabia sem mim, mas o que Monitor.Enter
, Monitor.Leave
, Monitor.TryEnter
é Monitor.TryEnter
é um tópico para um relatório completo, denso e separado. Acredite, tudo dentro dele é muito, muito legal. Esta é uma primitiva de sincronização híbrida criada para evitar fome, escapamentos excessivos de bloqueio e comboio de bloqueio. - Até três relatórios sólidos sobre bloqueios e sem espera, incluindo o exemplo de drones de reconhecimento e defesa aérea, tentando derrubar esses drones. E esses relatórios foram tão apreciados pelo HighLoad ++ que foram chamados para o HighLoad ++ em Moscou nos dias 07 e 08 de novembro .
- Uma série de relatórios sobre PLINQ e Async-Await. Tudo também é o mais detalhado possível. Não pelo relógio: esse material é suficiente na Internet. Cada tecnologia será informada "de dentro": como é habitual no CLRium.
- E o seminário será encerrado por dois relatórios sobre a biblioteca de coleções sem bloqueios da Microsoft e da Intrinsics (instruções vetoriais para paralelização no nível do processador).
Algumas estatísticas
Somos o maior seminário do país e, em geral, não somos uma conferência apenas porque gostamos do nosso formato. Você não escolhe entre os relatórios para os quais não irá. Você vai por tudo. Além disso, você entende antecipadamente que todos os tópicos do seminário são do seu interesse, porque o tema é um. Outro recorde será estabelecido no CLRium 6: 700 pessoas estarão presentes nas duas cidades. Cerca de 700 pessoas desenvolvem suas habilidades em paralelismo e trabalham com a concorrência. E eles vão para entrevistas. Venha e você para nós :).