Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.17.230] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата Pavia @ Если делать всё грамотно, никаких дедлоков не будет. Менеджер памяти использует критические секции и ничего не лочится.Критические секции ведут к дедлокам. Спинлоки в этом плане как-то по понятие. Но тоже народ тоже не задумывается о дедлоках. Поэтому они тоже приводят к дедлокам. К тому же, дедлоки происходят тогда, когда используется минимум 2 критические секции (в смысле, объекты - мьютексы). |
Сообщ.
#17
,
|
|
|
Цитата Pavia @ Не понял как это работает.Но лично я решаю проблемы архитектурно шаблон генерал-подчинённый. Там дедлоки исключены. У каждого потока свои данные, а передачу данных от одного потока к другому осуществляет генерал. За графику и окошки отвечает один поток. - пользователь у нас один ему хватит и одного потока. А вот обработку данных делают разные потоки. Вот у потока с GDI есть всякие списки, свойства и пр. Нужно 2-м потокам изменить одновременно эти данные. Что для этого делается? |
Сообщ.
#18
,
|
|
|
Цитата Jin X @ Вот у потока с GDI есть всякие списки, свойства и пр. Нужно 2-м потокам изменить одновременно эти данные. Что для этого делается? Что есть "поток с GDI"? В целом поверьте человеку, наевшемуся с потоками. Во избежание слома мозга из-за таинственных глюков по причине неучстенного совместного доступа к памяти или дедлоков взаимодействие между потоками надо максимально развязывать (см. PostThreadMessage). Данные предпочтительнее копировать, нежели блокировать. Если же блокировок не избежать, они д.б. как можно более короткими. |
Сообщ.
#19
,
|
|
|
Цитата Fr0sT @ Я хочу понять принцип "генерал-подчинённый".Что есть "поток с GDI"? Есть 2 потока, им обоим нужно получить доступ к каким-либо данным. Цитата Fr0sT @ Ты про Delphi конкретно?В целом поверьте человеку, наевшемуся с потоками. Если да, то вопросов нет - тут всё понятно. |
Сообщ.
#20
,
|
|
|
Цитата Jin X @ Я хочу понять принцип "генерал-подчинённый". Есть 2 потока, им обоим нужно получить доступ к каким-либо данным. "принцип "генерал-подчинённый"" это очень расплывчато. Предполагаю, в данном случае это означает, что один поток является "владельцем" данных (может манипулировать ими в любой момент), а остальным позволяется получать к ним доступ только по сигналу. Подходы есть разные. Есть slim reader-writer (как в виде winapi объекта, так и эмуляцией через две крит. секции), когда кол-во одновременно читающих потоков не ограничено. Есть принцип Go - никаких разделяемых данных, строго копирование. Есть классические крит. секции. Цитата Jin X @ Ты про Delphi конкретно? Да нет, это любого языка касается (ну кроме Go, там по-другому и не сделаешь) |
Сообщ.
#21
,
|
|
|
Цитата Fr0sT @ Ну это высокоуровневые проблемы. С WinAPI же вроде как таких проблем нет...Да нет, это любого языка касается Цитата Fr0sT @ Я думаю, что Pavia что-то другое имел в виду, т.к. ридером может быть и основной поток.Есть slim reader-writer (как в виде winapi объекта, так и эмуляцией через две крит. секции) Цитата Fr0sT @ Что значит "копирование" в данном случае? Чтение? А как же запись? Есть принцип Go - никаких разделяемых данных, строго копирование. |
Сообщ.
#22
,
|
|
|
Цитата Jin X @ С WinAPI же вроде как таких проблем нет... Такие проблемы есть везде, где есть потоки и разделяемые области памяти. Хоть на ассемблере Цитата Jin X @ Что значит "копирование" в данном случае? Чтение? А как же запись? Копирование - это копирование. Записи никакой не предусмотрено. Надо передать потоку данные - отправляй копию. Жёстко, но полностью исключает проблемы совместного доступа |
Сообщ.
#23
,
|
|
|
Цитата Fr0sT @ А что с записью? Тоже через посредника?Копирование - это копирование. Записи никакой не предусмотрено. Надо передать потоку данные - отправляй копию. Жёстко, но полностью исключает проблемы совместного доступа Цитата Fr0sT @ Давай пример при работы с GDI через WinAPI из 2-х потоков одновременно. Но чтобы косяк был не в коде (типа обработчика сообщений, который пишет куда-то). Такие проблемы есть везде, где есть потоки и разделяемые области памяти. |
Сообщ.
#24
,
|
|
|
Цитата Jin X @ А что с записью? Тоже через посредника? Записью чего? Куда? Откуда? Данные существуют только в одном экземпляре, у владельца. Передача через копирование. Что непонятного? Цитата Jin X @ Давай пример при работы с GDI через WinAPI из 2-х потоков одновременно. Но чтобы косяк был не в коде (типа обработчика сообщений, который пишет куда-то). Разговор зашел не в ту степь. Есть вопрос - спрашивай конкретно, давать какие-то примеры для доказательства непонятно чего мне совсем не вперлось |
Сообщ.
#25
,
|
|
|
Цитата Fr0sT @ Речь начиналась о критических секциях, насколько я помню.Записью чего? Куда? Откуда? Данные существуют только в одном экземпляре, у владельца. Передача через копирование. Что непонятного? Кто-то читает данные, а кто-то их пишет. Если чтение производится через посредника путём передачи копии, то как в этом механизме происходит запись этих данных? Цитата Fr0sT @ Причём тут доказательство? Я хочу понять что ты имеешь в виду: в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков? Разговор зашел не в ту степь. Есть вопрос - спрашивай конкретно, давать какие-то примеры для доказательства непонятно чего мне совсем не вперлось |
Сообщ.
#26
,
|
|
|
Цитата Jin X @ Если чтение производится через посредника путём передачи копии, то как в этом механизме происходит запись этих данных? Так же как и чтение. Потоку-владельцу присылается копия данных, он уже решает, что с ними делать Цитата Jin X @ Я хочу понять что ты имеешь в виду: в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков? Да легко. Попробуй рисовать на канвасе из двух потоков одновременно. Многие объекты в winapi thread-safe, но не все. |
Сообщ.
#27
,
|
|
|
Цитата Jin X @ в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков? Чего ты привязался к этому "WinAPI (GDI)"? Конкретизируй вопрос. Первоначально речь шла только о показе MessageBox из доп.потока. Тут "проблемы" могут быть только в логике организации взаимодействия с юзером. Например, блокируешь ты основную форму на время показа MessageBox или нет. При hWnd=0 (как у тебя в примере #1) форма не блокируется и оба окна ведут себя независимо, поэтому весь расчет на то, что разумный юзер должен сначала закрыть МБ прежде чем тыкать кнопки\меню на форме. Но иногда возможны нештатные ситуации, когда в результате "не пойми чего" форма вылезает на передний план, закрывая МБ, и юзер (не замечая второго окна приложения на панели задач) начинает тыкать по форме, а МБ продолжает "благополучно висеть" под формой вместе со своим потоком. Если же блокировать форму на время показа МБ (передавая ее hWnd в МБ), то ситуация становится более понятной\предсказуемой, но только в том случае, если показывается только один МБ. Если же у тебя несколько потоков могут одновременно показывать МБ (или не дай бог основной поток выдаст ShowMessage), то ситуация может быть еще более запутанной\непредсказуемой. Видимо "один товарищ" (упомянутый в посте #7) это и имел ввиду, а не то, что возможны какие-то критические ситуации с дедлоками, AV и т.п. Добавлено Цитата Fr0sT @ Да легко. Попробуй рисовать на канвасе из двух потоков одновременно. На разных канвасах (оконных DC) - "легко". Винда без проблем отрисовывает десятки перекрывающихся окон, даже если они пытаются рисовать себя полностью, а не только видимую часть - все излишние "художества" благополучно вырезаются и на экран выводится общая картинка в соответствии с Z-порядком отображения окон. |
Сообщ.
#28
,
|
|
|
Цитата leo @ На этот случай есть MB_TASKMODAL, который я комбинирую с MB_SETFOREGROUND.Но иногда возможны нештатные ситуации, когда в результате "не пойми чего" форма вылезает на передний план, закрывая МБ, и юзер (не замечая второго окна приложения на панели задач) начинает тыкать по форме, а МБ продолжает "благополучно висеть" под формой вместе со своим потоком. Цитата leo @ Такой задачи-то и нет . Всё надо с умом делать Если же блокировать форму на время показа МБ (передавая ее hWnd в МБ), то ситуация становится более понятной\предсказуемой, но только в том случае, если показывается только один МБ. Если же у тебя несколько потоков могут одновременно показывать МБ (или не дай бог основной поток выдаст ShowMessage), то ситуация может быть еще более запутанной\непредсказуемой Цитата leo @ "Один товарищ", как выяснилось имел в виду ShowMessage, хотя разговор явно шёл про MessageBox. Ну перепутал он Видимо "один товарищ" (упомянутый в посте #7) Цитата Fr0sT @ Так, а что будет-то? Мне прямо даже интересно Да легко. Попробуй рисовать на канвасе из двух потоков одновременно. Многие объекты в winapi thread-safe, но не все. И где-то вообще есть инфа о не-thread-safe-функциях? |
Сообщ.
#29
,
|
|
|
Цитата leo @ На разных канвасах (оконных DC) - "легко". Винда без проблем отрисовывает десятки перекрывающихся окон, даже если они пытаются рисовать себя полностью, а не только видимую часть - все излишние "художества" благополучно вырезаются и на экран выводится общая картинка в соответствии с Z-порядком отображения окон. Хитрый какой! )) Нет, я имел в виду на одном канвасе. |