Затык с сообщениями , отправляется 2, приходит 1

[Jin X]

Цитата Pavia @ 09.09.17, 09:11

Критические секции ведут к дедлокам. Спинлоки в этом плане как-то по понятие. Но тоже народ тоже не задумывается о дедлоках. Поэтому они тоже приводят к дедлокам.

Если делать всё грамотно, никаких дедлоков не будет. Менеджер памяти использует критические секции и ничего не лочится.
К тому же, дедлоки происходят тогда, когда используется минимум 2 критические секции (в смысле, объекты - мьютексы).

[Jin X]

Цитата Pavia @ 09.09.17, 09:11

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

Не понял как это работает.
Вот у потока с GDI есть всякие списки, свойства и пр. Нужно 2-м потокам изменить одновременно эти данные. Что для этого делается?

[Fr0sT]

Цитата Jin X @ 09.09.17, 17:47

Вот у потока с GDI есть всякие списки, свойства и пр. Нужно 2-м потокам изменить одновременно эти данные. Что для этого делается?

Что есть "поток с GDI"?

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

[Jin X]

Цитата Fr0sT @ 11.09.17, 07:14

Что есть "поток с GDI"?

Я хочу понять принцип "генерал-подчинённый".
Есть 2 потока, им обоим нужно получить доступ к каким-либо данным.

Цитата Fr0sT @ 11.09.17, 07:14

В целом поверьте человеку, наевшемуся с потоками.

Ты про Delphi конкретно?
Если да, то вопросов нет - тут всё понятно.

[Fr0sT]

Цитата Jin X @ 11.09.17, 12:10

Я хочу понять принцип "генерал-подчинённый".
Есть 2 потока, им обоим нужно получить доступ к каким-либо данным.

"принцип "генерал-подчинённый"" это очень расплывчато. Предполагаю, в данном случае это означает, что один поток является "владельцем" данных (может манипулировать ими в любой момент), а остальным позволяется получать к ним доступ только по сигналу.
Подходы есть разные. Есть slim reader-writer (как в виде winapi объекта, так и эмуляцией через две крит. секции), когда кол-во одновременно читающих потоков не ограничено. Есть принцип Go - никаких разделяемых данных, строго копирование. Есть классические крит. секции.

Цитата Jin X @ 11.09.17, 12:10

Ты про Delphi конкретно?

Да нет, это любого языка касается (ну кроме Go, там по-другому и не сделаешь)

[Jin X]

Цитата Fr0sT @ 11.09.17, 14:34

Да нет, это любого языка касается

Ну это высокоуровневые проблемы. С WinAPI же вроде как таких проблем нет...

Цитата Fr0sT @ 11.09.17, 14:34

Есть slim reader-writer (как в виде winapi объекта, так и эмуляцией через две крит. секции)

Я думаю, что Pavia что-то другое имел в виду, т.к. ридером может быть и основной поток.

Цитата Fr0sT @ 11.09.17, 14:34

Есть принцип Go - никаких разделяемых данных, строго копирование.

Что значит "копирование" в данном случае? Чтение? А как же запись?

[Fr0sT]

Цитата Jin X @ 11.09.17, 15:36

С WinAPI же вроде как таких проблем нет...

Такие проблемы есть везде, где есть потоки и разделяемые области памяти. Хоть на ассемблере

Цитата Jin X @ 11.09.17, 15:36

Что значит "копирование" в данном случае? Чтение? А как же запись?

Копирование - это копирование. Записи никакой не предусмотрено. Надо передать потоку данные - отправляй копию.
Жёстко, но полностью исключает проблемы совместного доступа

[Jin X]

Цитата Fr0sT @ 13.09.17, 15:31

Копирование - это копирование. Записи никакой не предусмотрено. Надо передать потоку данные - отправляй копию.
Жёстко, но полностью исключает проблемы совместного доступа

А что с записью? Тоже через посредника?

Цитата Fr0sT @ 13.09.17, 15:31

Такие проблемы есть везде, где есть потоки и разделяемые области памяти.

Давай пример при работы с GDI через WinAPI из 2-х потоков одновременно. Но чтобы косяк был не в коде (типа обработчика сообщений, который пишет куда-то).

[Fr0sT]

Цитата Jin X @ 20.09.17, 16:35

А что с записью? Тоже через посредника?

Записью чего? Куда? Откуда? Данные существуют только в одном экземпляре, у владельца. Передача через копирование. Что непонятного?

Цитата Jin X @ 20.09.17, 16:35

Давай пример при работы с GDI через WinAPI из 2-х потоков одновременно. Но чтобы косяк был не в коде (типа обработчика сообщений, который пишет куда-то).

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

[Jin X]

Цитата Fr0sT @ 21.09.17, 07:11

Записью чего? Куда? Откуда? Данные существуют только в одном экземпляре, у владельца. Передача через копирование. Что непонятного?

Речь начиналась о критических секциях, насколько я помню.
Кто-то читает данные, а кто-то их пишет. Если чтение производится через посредника путём передачи копии, то как в этом механизме происходит запись этих данных?

Цитата Fr0sT @ 21.09.17, 07:11

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

Причём тут доказательство? Я хочу понять что ты имеешь в виду: в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков?

[Fr0sT]

Цитата Jin X @ 21.09.17, 11:59

Если чтение производится через посредника путём передачи копии, то как в этом механизме происходит запись этих данных?

Так же как и чтение. Потоку-владельцу присылается копия данных, он уже решает, что с ними делать

Цитата Jin X @ 21.09.17, 11:59

Я хочу понять что ты имеешь в виду: в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков?

Да легко. Попробуй рисовать на канвасе из двух потоков одновременно.
Многие объекты в winapi thread-safe, но не все.

[leo]

Цитата Jin X @ 21.09.17, 11:59

в каких случаях (например) возможны проблемы при обращении к WinAPI (GDI) одновременно двух потоков?

Чего ты привязался к этому "WinAPI (GDI)"? Конкретизируй вопрос.
Первоначально речь шла только о показе MessageBox из доп.потока. Тут "проблемы" могут быть только в логике организации взаимодействия с юзером. Например, блокируешь ты основную форму на время показа MessageBox или нет. При hWnd=0 (как у тебя в примере #1) форма не блокируется и оба окна ведут себя независимо, поэтому весь расчет на то, что разумный юзер должен сначала закрыть МБ прежде чем тыкать кнопки\меню на форме. Но иногда возможны нештатные ситуации, когда в результате "не пойми чего" форма вылезает на передний план, закрывая МБ, и юзер (не замечая второго окна приложения на панели задач) начинает тыкать по форме, а МБ продолжает "благополучно висеть" под формой вместе со своим потоком.
Если же блокировать форму на время показа МБ (передавая ее hWnd в МБ), то ситуация становится более понятной\предсказуемой, но только в том случае, если показывается только один МБ. Если же у тебя несколько потоков могут одновременно показывать МБ (или не дай бог основной поток выдаст ShowMessage), то ситуация может быть еще более запутанной\непредсказуемой. Видимо "один товарищ" (упомянутый в посте #7) это и имел ввиду, а не то, что возможны какие-то критические ситуации с дедлоками, AV и т.п.

Добавлено 22.09.17, 07:06

Цитата Fr0sT @ 21.09.17, 16:13

Да легко. Попробуй рисовать на канвасе из двух потоков одновременно.

На разных канвасах (оконных DC) - "легко". Винда без проблем отрисовывает десятки перекрывающихся окон, даже если они пытаются рисовать себя полностью, а не только видимую часть - все излишние "художества" благополучно вырезаются и на экран выводится общая картинка в соответствии с Z-порядком отображения окон.

[Jin X]

Цитата leo @ 22.09.17, 06:52

Но иногда возможны нештатные ситуации, когда в результате "не пойми чего" форма вылезает на передний план, закрывая МБ, и юзер (не замечая второго окна приложения на панели задач) начинает тыкать по форме, а МБ продолжает "благополучно висеть" под формой вместе со своим потоком.

На этот случай есть MB_TASKMODAL, который я комбинирую с MB_SETFOREGROUND.

Цитата leo @ 22.09.17, 06:52

Если же блокировать форму на время показа МБ (передавая ее hWnd в МБ), то ситуация становится более понятной\предсказуемой, но только в том случае, если показывается только один МБ. Если же у тебя несколько потоков могут одновременно показывать МБ (или не дай бог основной поток выдаст ShowMessage), то ситуация может быть еще более запутанной\непредсказуемой

Такой задачи-то и нет . Всё надо с умом делать

Цитата leo @ 22.09.17, 06:52

Видимо "один товарищ" (упомянутый в посте #7)

"Один товарищ", как выяснилось имел в виду ShowMessage, хотя разговор явно шёл про MessageBox. Ну перепутал он

Цитата Fr0sT @ 21.09.17, 16:13

Да легко. Попробуй рисовать на канвасе из двух потоков одновременно.
Многие объекты в winapi thread-safe, но не все.

Так, а что будет-то? Мне прямо даже интересно
И где-то вообще есть инфа о не-thread-safe-функциях?

[Fr0sT]

Цитата leo @ 22.09.17, 06:52

На разных канвасах (оконных DC) - "легко". Винда без проблем отрисовывает десятки перекрывающихся окон, даже если они пытаются рисовать себя полностью, а не только видимую часть - все излишние "художества" благополучно вырезаются и на экран выводится общая картинка в соответствии с Z-порядком отображения окон.

Хитрый какой! )) Нет, я имел в виду на одном канвасе.