![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Приоритет разблокирования
Jump © (2007-03-20 06:46:00)Здравствуйте уважаемые!
Вопрос: есть ли в винде средства для управления приоритетом разблокирования потоков? Т.е. у меня есть несколько потоков, есть критическая секция, на которой они периодически блокируются, и хотелось бы, чтобы при разблокировании в первую очередь это делали именно определенные потоки.
GrayFace (2007-03-23 22:29:00) [1]Наверное, thread pool поможет.
Jump (21.03.07 12:10) [5]
Основные способы, на сколько я знаю - это мютексы и семафоры.
Я чаще всего использую критические секции и Event-ы.
MikePetrichenko © (22.03.07 2:14) [13]
Да, кстати, в теории, ее можно использовать между процессами.
Нет, хэндл нужен каждому процессу свой, поэтому в MMF не засунуть, в то же время LockCount должен быть общим. Только если вручную реализовать аналогичное поведение, как сделал Рихтер.
SLoW.AlfaMoon.Com (2007-03-23 13:42:00) [2]Почитайте обсуждение (посты SLoW и Набережных С.)
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=48988
Riply (2007-03-22 16:56:00) [3]>[14] Наиль © (22.03.07 15:26)
>Следовательно, программа опирающаяся на приоритеты потоков, может работать различно в разных ОС.
С этим никто и не спорит :)
Как я поняла из прведенной ссылки, утверждение Рихтера (выделенное),
за исключением одного момента, справедливо и для Vista.
А именно: нельзя планировать какой поток "пробудится при освобождении объекта".
В Vista "честный алгоритм" просто стал более честным :).
Но как не было никаких гарантий, так и не появилось.
А исключение, про которое я говорила, это то, что в XP, например,
могло получиться так, что поток вообще никогда не проснется,
а "поток в ОС Windows Vista всегда получит, по крайней мере, свою очередь выполнения".
Наиль (2007-03-22 15:26:00) [4]> [11] Riply © (22.03.07 00:06)
(c) Jeffrey Richter
Поведение потоков в Vista отличается от поведения в предыдущих версиях.
http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/default.aspx?loc%3dru&pf=true&loc=ru
Следовательно, программа опирающаяся на приоритеты потоков, может работать различно в разных ОС.
MikePetrichenko (2007-03-22 02:14:00) [5]"The threads of a single process can use a critical section object for mutual-exclusion synchronization. There is no guarantee about the order in which threads will obtain ownership of the critical section, however, the system will be fair to all threads."
Думаю понятно, почему только в пределах одного процесса. Далле:
_RTL_CRITICAL_SECTION = record
DebugInfo: PRTLCriticalSectionDebug;
LockCount: Longint;
RecursionCount: Longint;
OwningThread: THandle;
LockSemaphore: THandle;
Reserved: DWORD;
end;
О чем это говорит? О том, что секция построена на семафоре. А что значит использование семафора? А то, что рано или поздно (а именно при захвате и освобождении) поток вывалится из пользовательского режима.
Да, кстати, в теории, ее можно использовать между процессами.
Riply (2007-03-22 00:09:00) [6]> [11] Riply © (22.03.07 00:06)
Извините. Что-то с copy/paste - текст исказился:(
Но смысл, надеюсь, - нет :)
Riply (2007-03-22 00:06:00) [7](c) Jeffrey Richter
Тут возникает интересный вопрос. Если несколько потоков ждет один объект ядра,
какой из них пробудится при освобождении этого объекта?
Официально Microsoft отвечает на этот вопрос так: «Алгоритм действует честно"
Что это за алгоритм, Micro soft не говорит, потому что нс хочст связывать себя
обязательствами всегда придер живаться именно этого алгоритма. Она утверждает
лишь одно- если объект ожидает ся несколькими потоками, то всякий раз,
когда этот объект переходит в свободное состояние, каждый из них получает шанс на пробуждение.
Таким образом, приоритет потока не имеет значения- поток с самым высоким
приоритетом не обязательно первым захватит объект. Не получает преимущества и поток,
который ждал дольше всех. Есть даже вероятность, что какой-то поток
сумеет повторно захватить объект.Конечно, это было бы нечестно по отношению к другим потокам,
и алгоритм пытается не допустить этого. Но никаких гарантий нет.
На самом деле этот алгоритм просто использует популярную схему
"первым во шел — первым вышел" (FIFO). B принципе, объект захватывается потоком,
ждавшим дольше всех. Но в системе могут произойти какие-то события,
которые повлияют на окончательное решение, и ил-за этого алгоритм становится менее предсказуемым.
Вот почему Microsoft и не хочет говорить, как именно он работает.
Одно из таких собы тий — приостановка какого-либо потока. Если поток ждет объект и
вдруг приоста навливается, система просто забывает, что он ждал этот объект.
А причина в том, что нет смысла планировать приостановленный поток.
Когда он в конце концов возоб новляется, система считает,
что он только что начал ждать данный объект.
Jump (2007-03-21 21:02:00) [8]Т.е. дело в приоритете.
Спасибо.
Leonid Troyanovsky (2007-03-21 18:22:00) [9]
> Rouse_ © (21.03.07 13:12) [6]
> Ты можешь повысить приоритет потока, тогда есть большой
> шанс, что он первый встанет в очередь
Поток с более высоким приоритетом разбудят раньше.
Гарантированно (с вероятностью = 1).
Кажись, такое зовется "почти наверное".
--
Regards, LVT.
Leonid Troyanovsky (2007-03-21 14:41:00) [10]
> Jump (21.03.07 12:10) [5]
> Критическая секция - по сути мютекс. Вход в критическую
> секцию - захват мютекса, выход - освобождение.
Критическая секция - это критическая секция.
Она построена так, чтобы поток, по возможности,
не выпадал из пользовательского режима.
--
Regards, LVT.
Сергей М. (2007-03-21 14:40:00) [11]
> Jump (21.03.07 12:10) [5]
Скорее всего, ты занимаешься фигней, и конечна задача твоя решается гораздо проще)
Rouse_ (2007-03-21 13:12:00) [12]Ты можешь повысить приоритет потока, тогда есть большой шанс, что он первый встанет в очередь
Jump (2007-03-21 12:10:00) [13]Rouse_ ©
Роуз, медаль хочешь? Из шоколада :)
Мне нужна помощь, а подобные посты...
Основные способы, на сколько я знаю - это мютексы и семафоры. Остальные - "сконструированы" из первых.
Критическая секция - по сути мютекс. Вход в критическую секцию - захват мютекса, выход - освобождение.
Мутекс содержит не то ФИФО, ни то ЛИФО стек, в котором хранится очередь идентификаторов потоков, блокированных на нем.
Т.е. конкретизируя вопрос, меня интересут возможность управления этим стеком. А еще конкретизируя, интресует возможность помещать идентификаторы потоков в разные концы этой очереди (высокоприоритетные ближе к выходу, низкоприоритетные - на вход).
Rouse_ (2007-03-20 17:59:00) [14]Кроме критических секций есть и другие способы синхронизации :)
Jump (2007-03-20 17:06:00) [15]> Чапаев © (20.03.07 08:04)
Я говорол не про "блокирование КС", а про блокирование потоков.
---------------------------------------------------------------------
>Сергей М.
>Нет таких средств.
А может кто-нибудь знает (возможно всем известный ;) ) способ это организовать?
Сергей М. (2007-03-20 08:44:00) [16]
> Jump (20.03.07 06:46)
Нет таких средств.
"Кто первый встал, того и тапки" (с)
Чапаев (2007-03-20 08:04:00) [17]То есть как? Кто её заблокировал, тот и разблокирует. Какие тут приоритеты быть могут?