Критическая секция между потоками на разных ядрах

[3D Hunter]

Собственно, вопрос по сабжу: есть критическая секция и 2 потока, ее использующие в своих методах. Программа зависает в 1 из 100 случаев, но статистика показала - улеты в облака наблюдаются. В коде ошибок нет априори, проверялось многократно, можно принять как факт.
Теперь мысли вслух и вопрос тут же. В случае одного ядра идет четкое попеременное разделение квантов времени между этими 2мя потоками процесса. Т.е. к объекту синхронизации оба потока ОДНОВРЕМЕННО обратиться физически просто не смогут. Но если процессор многоядерный, а при запуске программы винда посчитала распределить эти 2 потока по разным ядрам, то получается этот 1 из 100 случаев: ситуация, когда в одну и ту же единицу времени оба потока обратятся к критической секции, т.е. вызов EnterCriticalSection(FRTL) произойдет одновременно в методах обоих потоков. Как ОС разрешает такой казус? Которому из потов отдается предпочтение? Или же ОС не решает такой задачи, что и приводит к задумчивости программы? Спасет ли форсирование аффинити-маски для этих двух потов и если да, то станет ли это причиной подтормаживания программы при загрузке ЦП другими процессами?
Чтобы было понятнее, скажу сразу: 1 поток постоянно делает что-то, а второй поток обращается к этому чему-то по щелчку пользователя. И вот при одном из таких "удачных" щелчков по контролу интерфейс зависает. Можете прокомментировать эту ситуацию? Прошу помочь в первую очередь знающих и опытных программистов! Заранее спасибо!

[Человек_Борща]

Может очередь?
Занято? В очередь, пока занято.

[3D Hunter]

А поконкретнее аналогию можно? Имеете ввиду аффинити-маски?

[Человек_Борща]

Заводим глобальный обьект крит. секции.

Когда потоку надо куда-то обратиться, он апроверяет: Есть ли крит. секция. Если нет, создает свою и вызывает заранее завернутый код.
Если Да, то отправляет в "поток 3" данные. Поток 3 ждет пока крит. секция не освободится, когда это происходит, поток 3 занимает крит. секцию с сбрасывает туда данные(заняв крит. секцию).

[rpy3uH]

Сообщение от 3D Hunter

Т.е. к объекту синхронизации оба потока ОДНОВРЕМЕННО обратиться физически просто не смогут. Но если процессор многоядерный, а при запуске программы винда посчитала распределить эти 2 потока по разным ядрам, то получается этот 1 из 100 случаев: ситуация, когда в одну и ту же единицу времени оба потока обратятся к критической секции, т.е. вызов EnterCriticalSection(FRTL) произойдет одновременно в методах обоих потоков. Как ОС разрешает такой казус? Которому из потов отдается предпочтение? Или же ОС не решает такой задачи, что и приводит к задумчивости программы? Спасет ли форсирование аффинити-маски для этих двух потов и если да, то станет ли это причиной подтормаживания программы при загрузке ЦП другими процессами?

критические секции специально заточены под это. конфликтов не происходит. пусть будет хоть 100 процессоров и по потоку на каждом и все они одновременно обратятся к критической секции, в критическую войдёт только один поток. там куча всяких мелочей, приводить здесь всю матчасть и подноготную операционной системы просто лень.

[Аватар]

Не пойму, зачем создавать еще левые потоки для организации ожидания освобождения крит.секции, если просто в потоке можно ждать этого освобождения? Чем это поможет ТС, если он в двух потоках использует одну критческую секцию? И что-то не слышал про проблемы критических секций для многоядерных процессоров. Скорее всего где-то в код ТС закралась ошибка, хотя он и обратное утверждает

[rpy3uH]

Сообщение от Человек_Борща

Заводим глобальный обьект крит. секции.

Когда потоку надо куда-то обратиться, он апроверяет: Есть ли крит. секция. Если нет, создает свою и вызывает заранее завернутый код.
Если Да, то отправляет в "поток 3" данные. Поток 3 ждет пока крит. секция не освободится, когда это происходит, поток 3 занимает крит. секцию с сбрасывает туда данные(заняв крит. секцию).

это костыль и изобретение велосипеда. критические секции специально сделаны для того чтобы не делать это. критические секции сделаны для удобства, а не для создания костылей

[EUGY]

вот при одном из таких "удачных" щелчков по контролу интерфейс зависает

То есть gui-поток вызвает EnterCriticalSection, но объект уже занят.
gui-поток сначала покрутится в спин-блокировке, потом уходит в режим ядра.
Из нирваны его выведет освобождение объекта синхронизации. Выводит, но долго ждать? Тогда может TryEnterCriticalSection?
Я так вижу.

[rpy3uH]

Сообщение от EUGY

gui-поток сначала покрутится в спин-блокировке, потом уходит в режим ядра.

крутиться на спин-блокировке можно только в ядре

[EUGY]

Сообщение от rpy3uH

крутиться на спин-блокировке можно только в ядре

Спасибо, правильно ли я понял: поток в вызове EnterCriticalSection переходит в режим ядра, пытается получить доступ к ресурсу в спин-блокировке. Планировщик потоков переключит контект только после этого.