|
|
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Как-то писал многопоточное приложение, в общем и целом все получилось. Приложение было гуишным. Каждый поток создавался из своей TPanel и в нужные моменты слал ей SendMessage или PostMessage, этого хватало для полноценного обмена информацией и всяких оповещений. В результате мне даже понравилось. А как быть в сервисе или консольном приложении, где окон нет? Вот надо мне оповестить основной поток о какой-нибудь промежуточной ерунде, произошедшей в отдельном потоке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 14:23 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Угу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 15:27 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Просто Трёп [игнорируется] Можно посылать сообщения потоку функцией PostThreadMessage. Тогда, если в потоке нет своего цикла обработки сообщений, его надо организовать при помощи например функции PeekMessage. Насчёт евентов - это хороший вариант, но надо понимать, что поток, который будет ожидать срабатывания события при помощи функции WaitForSingleObject или WaitForMultipleObjects, будет в состоянии ожидания. Службы никогда не писал (вроде, не припоминаю такого :) ) не особо представляю, что там удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 15:28 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
А обратно? Оно в обе стороны будет работать? Насчет событий, ну в моей практике отношения между потоками обычно были несимметричными. Например один поток подготавливает какие-то данные и выдает другому, чтобы тот передал их по сети. Или один поток всё время обменивается данными с каким-то устройством и периодически или сам их выдает или у него запрашивают какие-то данные. Вот кстати со скуля один человек учебник написал несколько лет назад про многопоточность: https://github.com/loginov-dmitry/multithread/blob/master/multithread_in_delphi_for_beginners.md https://resql.ru/forum/topic.php?fid=58&tid=2036872 Правда не скажу сейчас, насколько хорошо написано, хотя начинал читать. ... |
|||
|
:
Изменено: 01.04.2024, 18:50 - s62
Нравится:
Не нравится:
|
|||
| 01.04.2024, 18:46 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
WaitForSingleObject можно ждать с таймаутом - опрашивая. Ну в щем надо какую-то пилить костыльную синхронизацию полюбому... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 18:48 |
|
||
|
Про многопоточность подскажите
|
|
|---|---|
|
#18+
в службе реализовывать обработку сообщений как в окне WinApi - не знаю, такая спорная имхо идея. Окно - оно и живёт за счёт этого цикла. А служба другим должна заниматься. Ну и тем более такой тяжеловесный механизм использовать для общения между потоками - плохо имхо. Из пушки по воробьям. у них же и так общая память. Мессаги - это IPC для общения между окнами windows и между визуальными приложениями. Потоки должны общаться через критически секции - вошел в неё , проверил, не пришло ли что-то, забрал, флаг снял, поехал далее. Так будет наивысшая производительность достигнута. ... |
|
|
:
|
|
| 01.04.2024, 18:55 |
|
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Ну и тем более такой тяжеловесный механизм использовать для общения между потоками - плохо имхо. Неизвестно, что за служба у Просто Трепа и что за обмен данными там между потоками. p.s. Один раз - сообщения от потока в другой доп. поток, так что там цикл обработки сообщений делали. А из доп. потока в основной поток GUI приложения передавать данные через PostMessage или оповещать через это, так это много раз использовал, это по-моему удобно. Ну со службами тут другая история. ... |
|||
|
:
Изменено: 01.04.2024, 19:05 - s62
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:00 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Ну и тем более такой тяжеловесный механизм использовать для общения между потоками - плохо имхо. Неизвестно, что за служба у Просто Трепа и что за обмен данными там между потоками. p.s. Один раз - сообщения от потока в другой доп. поток, так что там цикл обработки сообщений делали. А из доп. потока в основной поток GUI приложения передавать данные через PostMessage или оповещать через это, так это много раз использовал, это по-моему удобно. Ну со службами тут другая история. Это же как раз преимущество потоков. Всего-то для них структуру в памяти организовать, таблицу, куда можно - добавить поток, добавить для него очередь сообщений. и через эту очередь общаться, используя CriticalSection. Это именно для потоков - классика. ... |
|||
|
:
Изменено: 01.04.2024, 19:08 - IT-Клоп
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:08 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Для паттернодрочеров - это паттерн Observer, где поток может подписаться на сообщения себе. Единственное - проверку надо в потоке костылить, это да. потому цикл придётся делать - для проверки очереди. Надо смотреть, что за задача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:12 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Надо смотреть, что за задача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:13 |
|
||
|
Про многопоточность подскажите
|
|
|---|---|
|
#18+
IT-Клоп [игнорируется] Один поток может подготавливать данные, потом "взводить" событие, а второй по событию их считывать и обрабатывать. Как одна из простых схем. ... |
|
|
:
|
|
| 01.04.2024, 19:21 |
|
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Да задача простая, отсюда забрал, туда запихал. Проблема только в том, что откуда берешь, может затыкаться по-своему, а куда пихаешь - по-своему. И на все это надо реагировать, буферизировать, если есть затык с пиханием. И со скоростями непонятно. Что делать, если скорость пихания по каким-то причинам станет меньше скорости забирания. Это надо как-то отслеживать, играть размером буфера, если явление временное, звонить админу, если постоянное... А скорость забирания заранее неизвестна. Может, 100 UDP пакетов в минуту, а может, 1. Щас оно в одном потоке работает, но если происходит затык, данные теряются, пока админ (или скрипт) сервис не перезапустит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:37 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Просто Трёп [игнорируется] Если схема такая, что один пихает данные, а второй берет их и потом куда-то отправляет, то очередь можно использовать. Поток, который пихает, добавляет элементы в очередь. А который берет и что-то с ними делает, забирает из очереди по мере возможности, пока в очереди что-то есть. Вот тут, если использовать не потокобезопасную очередь, можно как раз использовать критическую секцию. Первый поток входит в секцию, добавляет элемент, выходит, второй входит, забирает, выходит. ... |
|||
|
:
Изменено: 01.04.2024, 19:47 - s62
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:41 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
Просто Трёп [игнорируется] Если схема такая, что один пихает данные, а второй берет их и потом куда-то отправляет, то очередь можно использовать. Поток, который пихает, добавляет элементы в очередь. А который берет и что-то с ними делает, забирает из очереди по мере возможности, пока в очереди что-то есть. О, надо будет зажурналировать потребление памяти службы и подождать, пока она заткнется. Посмотреть, увеличится жор памяти или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:46 |
|
||
|
Про многопоточность подскажите
|
|||
|---|---|---|---|
|
#18+
В любом случае, нужен буфер на случай затыка отправки и возможность дампить этот буфер, если затык критический. А уж если делать хороший FIFO буфер, то и потоки надо делать.... Хороший буфер он сам по себе многопоточный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2024, 19:48 |
|
||
|
Про многопоточность подскажите
|
|
|---|---|
|
#18+
Просто Трёп [игнорируется] Очереди-то есть: https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.Generics.Collections.TQueue https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.Generics.Collections.TThreadedQueue Я когда-то сам на основе динамического массива очередь делал. Но тут уже готовые. ) ... |
|
|
:
|
|
| 01.04.2024, 19:50 |
|
|
|
start [/forum/topic.php?fid=16&msg=749022&tid=16781]: |
0ms |
get settings: |
22ms |
get forum list: |
6ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
1343ms |
get tp. blocked users: |
2ms |
| others: | 40ms |
| total: | 1463ms |
| 0 / 0 |
