На что заменить критические секции в Vista?

← →
Riply © (2008-12-19 17:01) [40]

Это лог:
0000003628 19.12 16:44:27.640 Start Step: 0 ID: 0 ActiveThreads: 1 The operation completed successfully 0000000001 0000000863
0000003864 19.12 16:44:27.640 Start Step: 0 ID: 3628 ActiveThreads: 2 The operation completed successfully 0000000002 0000000864
0000003952 19.12 16:44:27.640 Start Step: 0 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000003 0000000865
0000003864 19.12 16:44:27.656 Break FIFO Step: 355 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000004 0000000866
0000003952 19.12 16:44:27.671 Break FIFO Step: 1106 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000005 0000000867
0000003952 19.12 16:44:27.671 Break FIFO Step: 1107 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000006 0000000868
0000003628 19.12 16:44:27.671 Break FIFO Step: 2070 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000007 0000000869
0000003864 19.12 16:44:27.671 Break FIFO Step: 1959 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000008 0000000870
0000003864 19.12 16:44:27.671 Break FIFO Step: 1960 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000009 0000000871
0000003864 19.12 16:44:27.671 Break FIFO Step: 1961 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000010 0000000872
0000003864 19.12 16:44:27.671 Break FIFO Step: 1962 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000011 0000000873
0000003864 19.12 16:44:27.671 Break FIFO Step: 1963 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000012 0000000874
0000003864 19.12 16:44:27.671 Break FIFO Step: 1964 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000013 0000000875
0000003864 19.12 16:44:27.671 Break FIFO Step: 1965 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000014 0000000876
0000003864 19.12 16:44:27.671 Break FIFO Step: 1966 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000015 0000000877
0000003864 19.12 16:44:27.671 Break FIFO Step: 1967 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000016 0000000878
0000003864 19.12 16:44:27.671 Break FIFO Step: 1968 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000017 0000000879
0000003864 19.12 16:44:27.671 Break FIFO Step: 1969 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000018 0000000880
0000003864 19.12 16:44:27.671 Break FIFO Step: 1970 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000019 0000000881
0000003864 19.12 16:44:27.671 Break FIFO Step: 1971 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000020 0000000882
0000003864 19.12 16:44:27.671 Break FIFO Step: 1972 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000021 0000000883
0000003864 19.12 16:44:27.671 Break FIFO Step: 1973 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000022 0000000884
0000003864 19.12 16:44:27.671 Break FIFO Step: 1974 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000023 0000000885
0000003864 19.12 16:44:27.671 Break FIFO Step: 1975 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000024 0000000886
0000003864 19.12 16:44:27.671 Break FIFO Step: 1976 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000025 0000000887
0000003864 19.12 16:44:27.671 Break FIFO Step: 1977 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000026 0000000888
0000003628 19.12 16:44:27.703 Break FIFO Step: 3599 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000027 0000000889
0000003628 19.12 16:44:27.703 Break FIFO Step: 3600 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000028 0000000890
0000003628 19.12 16:44:27.703 Break FIFO Step: 3601 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000029 0000000891
0000003628 19.12 16:44:27.703 Break FIFO Step: 3602 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000030 0000000892
0000003628 19.12 16:44:27.703 Break FIFO Step: 3603 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000031 0000000893
0000003864 19.12 16:44:27.703 Break FIFO Step: 3638 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000032 0000000894
0000003952 19.12 16:44:27.718 Break FIFO Step: 4495 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000033 0000000895
0000003952 19.12 16:44:27.718 Break FIFO Step: 4497 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000034 0000000896
0000003952 19.12 16:44:27.718 Break FIFO Step: 4498 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000035 0000000897
0000003952 19.12 16:44:27.718 Break FIFO Step: 4499 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000036 0000000898
0000003952 19.12 16:44:27.718 Break FIFO Step: 4500 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000037 0000000899
0000003952 19.12 16:44:27.718 Break FIFO Step: 4501 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000038 0000000900
0000003952 19.12 16:44:27.718 Break FIFO Step: 4502 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000039 0000000901
0000003952 19.12 16:44:27.718 Break FIFO Step: 4503 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000040 0000000902
0000003952 19.12 16:44:27.718 Break FIFO Step: 4504 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000041 0000000903
0000003952 19.12 16:44:27.718 Break FIFO Step: 4505 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000042 0000000904
0000003952 19.12 16:44:27.718 Break FIFO Step: 4506 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000043 0000000905
0000003952 19.12 16:44:27.718 Break FIFO Step: 4507 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000044 0000000906
0000003864 19.12 16:44:27.718 Break FIFO Step: 4778 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000045 0000000907
0000003864 19.12 16:44:27.718 Break FIFO Step: 4779 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000046 0000000908
0000003864 19.12 16:44:27.734 Break FIFO Step: 5168 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000047 0000000909
0000003864 19.12 16:44:27.734 Break FIFO Step: 5169 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000048 0000000910
0000003952 19.12 16:44:27.765 Break FIFO Step: 7894 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000049 0000000911
0000003864 19.12 16:44:27.796 Break FIFO Step: 9287 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000050 0000000912
0000003864 19.12 16:44:27.796 Break

← →
Riply © (2008-12-19 17:06) [41]

Не уместился. Вот его кончик:
0000003864 19.12 16:44:27.734 Break FIFO Step: 5169 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000048 0000000910
0000003952 19.12 16:44:27.765 Break FIFO Step: 7894 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000049 0000000911
0000003864 19.12 16:44:27.796 Break FIFO Step: 9287 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000050 0000000912
0000003864 19.12 16:44:27.796 Break FIFO Step: 9288 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000051 0000000913
0000003628 19.12 16:44:27.796 Stop Step: 9999 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000052 0000000914
0000003864 19.12 16:44:27.796 Stop Step: 9999 ID: 3864 ActiveThreads: 2 The operation completed successfully 0000000053 0000000915
0000003952 19.12 16:44:27.796 Stop Step: 9999 ID: 3952 ActiveThreads: 1 The operation completed successfully 0000000054 0000000916

И немного пояснений:
С трудом удалось подобрать маленький лог.
Обычно (при этих параметрах) было, примерно, 200 - 300 записей (нить повторно захватывала объект).
Бывало, что и ни одной. Это когда не закрывая приложение, прогоняем тест раз десять.

← →
Добежал (2008-12-19 17:39) [42]

это к чему все?

← →
Riply © (2008-12-19 17:53) [43]

> [42] Добежал (19.12.08 17:39)
> это к чему все?

К тому, что мне пришлось выбирать между такими вариантами:
1. Ты не умеешь читать.
2. Ты умеешь читать, но не умеешь понимать что написано.
3. Ты настоль закомплексован, что не можешь призать свою ошибку
и будешь стоять на своем до последнего (часто подтасовывая факты).
4. Ты просто еще до конца не разобрался.

Т.к. я исходно думаю о людях хорошо, то остановилась на последнем варианте
и не поленилась для тебя написать код, доказывающий, что под XP потоки
могли захватывать объект не по FIFO

← →
Городской Шаман (2008-12-19 18:28) [44]

> Добежал (19.12.08 14:24) [24]
>
> попытаюсь объяснить, почему так считаю. Ведь Sleep(x) это
> комманда, которая говорит диспетчеру потоков, что потоку
> не нужно процесорное время еще x миллисекунд. Все пользуются
> тем, что sleep(0) приводит к переключению контекста, но
> ведь это я думаю нигде не запротоколировано. Поэтому не
> совсем верно так писать.

Как я делал. У меня была очередь пакетов на обработку, которые ставили в эту очередь другие потоки. Рабочий поток обрабатывающий очередь при "всплывании" сперва вычитывал и обрабатывал все пакеты без sleep(0) как только при очередной итерации count =0 то в теле итерации происходило переключение не на блок обработки а на блок sleep(0);

Тоесть пока нет заданий, мы получаем пакеты и обрабатываем, как только все задания закончились - поток в сон.

← →
Добежал (2008-12-22 11:38) [45]

> переключение не на блок обработки а на блок sleep(0);

Игорь Шевченко ясно же показал, что sleep(0) вовсе не обязательно должно переключить поток. В принципе, поток после этого может продолжать выполняться.

В принципе, это и логично. Sleep - комманда, которая говорит потоку "зависнутЬ" на такое-то время. Это особенность, что при sleep(0) обычно происходит переключение потоков. Но это не задокументировано и делать так в общем-то неправильно (полагаться на это).

← →
Городской Шаман (2008-12-22 14:20) [46]

> Добежал (22.12.08 11:38) [45]
> В принципе, это и логично. Sleep - комманда, которая говорит
> потоку "зависнутЬ" на такое-то время. Это особенность, что
> при sleep(0) обычно происходит переключение потоков. Но
> это не задокументировано и делать так в общем-то неправильно
> (полагаться на это).

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution.
http://msdn.microsoft.com/en-us/library/ms686298(VS.85).aspx

← →
Добежал (2008-12-22 16:02) [47]

А вот это уже интересно. Хотелось бы услышать комментарии Игоря Шевченко, ибо данный текст из MSDN немного противоречит Игорю:

Sleep приводит к ожиданию потока на объекте ядра "таймер". В случае интервала таймера равного нулю, таймер просто срабатывает мгновенно, но срабатывает весь механизм диспетчеризации потоков. Поэтому после sleep(0) поток может продолжать выполняться, как ни в чем не бывало, без переключения на другие потоки

а вот судя по MSDN, он НЕ может продолжать выполняться как ни в чем не бывало, если есть другие потоки равного приоритета.

← →
Городской Шаман (2008-12-22 18:01) [48]

> Добежал (22.12.08 16:02) [47]
> а вот судя по MSDN, он НЕ может продолжать выполняться как
> ни в чем не бывало, если есть другие потоки равного приоритета.

и они готовы к выполнению.

← →
Добежал (2008-12-22 18:08) [49]

ну я думаю ожидание над объектом ядра, который освободился, можно причислить к ситуации "они готовы к выполнению". Или нет?

← →
Игорь Шевченко © (2008-12-22 18:17) [50]

Добежал (22.12.08 16:02) [47]

> If there are no other threads of equal priority ready to
> run, the function returns immediately, and the thread continues
> execution.

Какое именно слово из процитированных противоречит моему посту ?

> Поэтому после sleep(0) поток может продолжать выполняться,
> как ни в чем не бывало, без переключения на другие потоки

?

← →
Добежал (2008-12-23 12:16) [51]

ну вероятно я вас неправильно понял

← →
vuk © (2008-12-23 13:06) [52]

Я в случаях, когда нужно обработка типа поставщики-потребитель и у заданий равный приоритет, я делаю так:

1. Есть потребитель, который большую часть времени тихо дрыхнет, отслушивая, как правило, пару Event-ов. Один event говорит, что есть данные на обработку, а второй - что пришла хана, надо сворачиваться и валить.

2. Есть буфер, в который поставщики складывают задания, по складыванию задания поднимается event, по которому просыпается потребитель. Доступ к буферу блокируется через CriticalSection.

3. По event-у о наличии данных потребитель просыпается, забирает всё, что есть в буфере в свой внутренний буфер и тихо там жует, не мешая поставщикам сваливать задания в общий буфер.

4. После того, как потребитель прожевал то, что ухватил, он идет спать.

← →
Добежал (2008-12-23 15:02) [53]

vuk, это все понятно. Но представь, что задания - это не некий посыл нечто сделать, а допустим каждый элемент списка - это некое устройство, которое нужно опрашивать.

То есть, извне добавляются / удаляются устройства в этом списке. А поток постоянно бегает по списку, опрашивая устройства. Более того, в результате опроса кое-какие служебные структуры меняются, то есть поток модифицирует структуры данных в этом списке. Причем, опрос идет постоянно, чем больше устройств - тем медленнее опрос получается.

В результате, мы имеем ситуацию, что поток постоянно работает со списком. И вот тут и случается описанная ситуация, этот поток сотни раз может входить и выходить из критической секции, синхронизирующей список, в то время как внешний поток который хочет добавить новое устройство может ждать десятки секунд (на Висте, на XP таких диких задержек не бывает никогда).

← →
vuk © (2008-12-23 15:29) [54]

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

← →
Eraser © (2008-12-23 17:12) [55]

> [52] vuk © (23.12.08 13:06)

классическая схема, оправдывает себя на 100%.
есть еще вариант с семафором, т.е.

1 поток (потребитель):

wait(sm1);
enter(cs);
// <<-- извлечение данных из буффера.
leave(cs);
release(sm2);

2 поток (обработчик (генератор) данных):
wait(sm2);
enter(cs);
// <<-- помещаем данные в буффер.
leave(cs);
release(sm1);

у семафоров MaximumCount = 1.
эта схема оправдана, когда работа двух потоков должна быть синхронизированна и выполнять одинаковое количество тактов.

← →
Добежал (2008-12-23 17:40) [56]

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

хм... Ну да, логику понял.

Но мне все таки кажется она немного избыточной. А зачем по сути этот промежуточный буфер нужен? Ведь добавлять устройство можно непосредственно в список, по крайней мере у меня это происходит редко. Если добавления / отключения частые - то наверное выгоден промежуточный буфер.

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

Разделение нужно исключительно для минимизации времени блокировки ресурса. При этом потребитель работает со своим внутренним списком данных, который блокировать не нужно вообще. Event нужен, как признак наличия данных в общем промежуточном буфере, что позволит не дергать лишний раз блоировку буфера для провеерки количества элементов. А уж когда этот event щупать - дело десятое.

> Добежал (23.12.08 15:02) [53]

> В результате, мы имеем ситуацию, что поток постоянно работает
> со списком. И вот тут и случается описанная ситуация, этот
> поток сотни раз может входить и выходить из критической
> секции, синхронизирующей список, в то время как внешний
> поток который хочет добавить новое устройство может ждать
> десятки секунд (на Висте, на XP таких диких задержек не
> бывает никогда).

Здесь нужен еще один Event, который выставляет писатель,
которому есть, что сказать, и при установке которого читатели
не должны приступать к чтению.
Т.е., при установке оного начавшие чтение еще дочитывают,
а новые ждут его сброса.

--
Regards, LVT.

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

> vuk © (23.12.08 19:38) [59]

> Не нужно этого ничего. Промежуточный буфер и один event
> в нем проблему решают.

Если есть +один (в нем) event, то и буфер не нужен.
Если, конечно, комментарий ко мне :)

--
Regards, LVT.

Что будет, если поток, обрабатывающий список, поставил блокировку и ушел в себя на некоторое время (кто его знает, что у него там внутри...)? Все будут его ждать?

> vuk © (23.12.08 21:00) [61]

> Что будет, если поток, обрабатывающий список, поставил блокировку
> и ушел в себя на некоторое время (кто его знает, что у него
> там внутри...)? Все будут его ждать?

А вот тут нужен mutex vs crit section with abandoned
или как его там.

--
Regards, LVT.

На что заменить критические секции в Vista? Найти похожие ветки