одной в ядре. Для минимизации расходов как раз и предпринимались всевозможные эксперименты с крит. секцией, мутексом, евентами. И разные схемы - синхронизация меж тредов процесса по отдельной схеме с крит. секцией и синхронизации процесс-ядро мутекосм/евентом, и совместная схема через один мутекс. Именно крит. секция с TryEnter создала больше всех накладных расходов. Использовать InterlockedCompareExchange не пришло никому в голову, из них использовали только инкремент-декремент в счетчиках, считающих везде, где попало. Кстати, возможно InterlockedCompareExchange, применная к ячейке физической памяти, замапленной параллельно и в ядро, и в юзер-процесс, можно было бы еще соптимизировать. Но сейчас это уже не очень это интересно.