Аналог EnterCriticalSection/LeaveCriticalSection в юзермоде

Приветствую.
В общем сабж.
Нужно реализовать синхронизацию потоков без этих функций

 

Тоесть kernel32 не юзоется, тогда заюзай ntdll, RtlEnterCriticalSection() и etc.

 

Я не точно сформулировал вопрос,
необходимо минимальное использование АПИ, в идеале вообще без них
Т.е. без RtlCriticalSection и без мутексов

 

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

 

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

 

Вот в чём я не согласен с Рихтером так это в том что это наихудший вариант из возможных Конечно если потоку обратившемуся к общим данным больше нечего делать как тупо ждать их готовности, то конечно же лучше поручить системе усыпить\разбудить его. Но так бывает не всегда - например есть поток с пользовательский интерфейсом, и поток - рабочая лошадка, который делает тяжёлый расчёт или работает с периодически тормозящей сетью и т.п. - здесь уже совсем неуместно усыплять интерфейсный поток поскольку тогда исчезает сам смысл разделения программы на потоки и лучше проверив свой флаг (или группу флагов) продолжить отображать на экране то что можно и строить комады рабочему потоку в очередь, которую он увидит когда освободится.
Например в StrongDC очень раздражает что при подвисаниях сети пользовательский интерфейс тоже глухо зависает.

 

Y_Mur

Не очень подходящий пример, т.к интерфейсный поток может и вздремнуть без ущерба интерфейсу, если поставит себе будильник MsgWaitForMultipleObjects
А ожидание в цикле проверки флага действительно может быть и не таким уж страшным при условии, что конфликт за ресурсы возникает не часто и длится недолго. А если два потока одновременно работают на разных ядрах\процессорах, то покрутить цикл с несколько сотен тактов даже выгоднее, чем заставлять систему переключать потоки, тем самым еще более напрягая процессор

 

PS: Кстати сам вход\выход в\из крит.секции занимает немало времени. Например, у "классического" брмановского менеджера памяти (не FastMM) на выделение+освобождение памяти без юзанья крит.секции уходит ~пара сотен тактов, а с крит.секцией до тысячи и более. Поэтому вполне возможно, что ожидание на флаге, а не крит.секции, здесь было бы вполне целесообразным с учетом того, что сама вероятность наложения сотни критических тактов в двух потоках сама по себе мала (ну или комбинированный вариант - ждем пару сотен тактов в цикле, затем уходим в монастыР - крит.секцию

 

leo
Ну интерфейс и на GetMessage неплохо поспать может отобразив при при этом на экране значки занятости где надо если это типа StrongDC. Или я делал прогу которая отображала физический объект, который можно было масштабировать и менять схему воздействия на него незовисимо от того уже рассчиталось его новое состояние или пока отображается старое с красным кружочком (сигнализирующем что расчёт не закончен) в уголке.

ЗЫ: ещё статейка в тему

 

локер из инферно

Код (Text):

1. ulong _tas(ulong *la){
2.     ulong v;
3.     _asm {
4.         mov eax, la
5.         mov ebx, 1
6.         xchg    ebx, [eax]
7.         mov v, ebx
8.     }
9.     return v;
10. }
11.  
12. int
13. canlock(rLock *l)
14. {
15.     return _tas(&l->val) == 0;
16. }
17.  
18. void
19. lock(rLock *l)
20. {
21.     int i;
22.  
23.     if(_tas(&l->val) == 0)
24.         return;
25.     for(i=0; i<100; i++){
26.         if(_tas(&l->val) == 0)
27.             return;
28.         osyield();
29.     }
30.     for(i=1;; i++){
31.         if(_tas(&l->val) == 0)
32.             return;
33.         osmillisleep(i*10);
34.         if(i > 100){
35.             osyield();
36.             i = 1;
37.         }
38.     }
39. }
40.  
41. void
42. unlock(rLock *l)
43. {
44.     l->val = 0;
45. }

вообще-то это кусок алефовского рантайма (на алефе, но вроде все понятно). там вообще практически вся многопоточность и канальность не через ось зарелизена.

 

TermoSINteZ

Какбы.. А проц юзать можно? Шутка.

Инферно/план9 имеют порты минимум на 5 платформ (больше. просто написалось 5). И кругом есть варианты реализации локеров/рфоркеров/канализаторов/болтунов/вытесняющей и кооперативной. Можно посмотреть если кросс нужен. Или вообще ядро потырить. Оно там маленькое. Инферновское хостовое, например. На выни и линях (кноппикс, убунту и асп) полет нормальный и крыльями машет одинаково.

 

Можно без обьектов сделоть. Смысл в том, что в сервисах ожидания можно разрешить обработку апк. Тоесть остальные потоки входят в сервис ожидания, можно в NtDelayExecution. После того, как первый вошедший в критическую секцию поток из неё выйдет, он поставит в очередь остальным потокам событие. Они выйдут из ожидания. Это в общем, нужно продумоть.

 

TermoSINteZ
что нить в духе
LOCK CMPXCHG DWORD PTR DS:[EDX+4],ECX

 

All
В юзермоде спин-блокировки не катят)