Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »
Страницы: 1 2 3 4

Снова многопоточность


rrrrrr ©   (19.08.17 09:47[60]

но есть несколько недостатков.....

1. все очень быстро напишется
2. подискутировать и порассусоливать будет не о чем дольше трех минут
3. портянки кода, вышеприведенные станут какими-то коротенькими


Leonid Troyanovsky ©   (19.08.17 10:03[61]


> Denchik   (19.08.17 00:09) [58]

Внимательно не смотрел, но смутила асинхронная посылка указателя
с последующим освобождением памяти (например,  строки 132, 133).

Безопасно можно слать <=8 байт (wparam, lparam).

--
Regards, LVT.


Leonid Troyanovsky ©   (19.08.17 10:19[62]


> rrrrrr ©   (19.08.17 09:44) [59]

> итого. универсальный случай для консоли и гуи.

Делать в консоли гуишные потоки не очень-то кошерно.

Да и, во-ще, если и делать нечто полезное, то начать надо с пула потоков, IMHO.

--
Regards, LVT.


Leonid Troyanovsky ©   (19.08.17 10:58[63]


> rrrrrr ©   (19.08.17 09:47) [60]

> 2. подискутировать и порассусоливать будет не о чем дольше
> трех минут

У мну есть 3 минуты, готов порассусоливать на такую тему:
диспетчер и рабочие потоки обмениваются данными через асинхронные сообщения, а решение о загрузке потоков диспетчер принимает
по статистике занятости потока  (GetThreadTimes?).

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

--
Regards, LVT.


rrrrrr ©   (19.08.17 11:19[64]

Делать в консоли гуишные потоки не очень-то кошерно.

во первых что такое гуишные потоки? во вторых где они у меня там?
в третьих с какого года и каким фз win32 консоли запрещено пользоваться гуи?

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


так все же просто.
однажды давно я тянул формы 101 и 102 с цб коих было миллион.
и сначала потоки были одноразовыми.
потом я подумал а зачем это собственно?
в результате они перестали умирать выполнив порцию работы.

то есть стал сендмессадж с результатом наверх. и по результатам сенда поток либо получал новое задание, либо умирал когда дело подошло к концу.

сверху был диспетчер, который еще считал, дает ли увеличение количества потоков прирост производительности показателю "получено форм в секунду"

и адаптивно выбирал всю полосу прокси которая доступна рабочему месту.

дома где я один и оптика можно было иметь линейный рост производительности где-то до нескольких сотен потоков.

а на работе было все уже печальнее. 10-15 потоков и все.
дальнейший рост просто тратил ресурсы не увеличивая скорость обработки


Leonid Troyanovsky ©   (19.08.17 16:15[65]


> rrrrrr ©   (19.08.17 11:19) [64]

> во первых что такое гуишные потоки? во вторых где они у
> меня там?
IsGUIThread function. Вызов Post(Thread)Message делает их таковыми.

> в третьих с какого года и каким фз win32 консоли запрещено
> пользоваться гуи?
Никем не запрещено. Просто не люблю котлеты с мухами.

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

У ТС речь идет о ловле блох (на фоне дисковых операций или, скажем,
скорости канала). Тут и SendMessage чемпион, но до всеобщей пользы,
IMHO, далековато.

--
Regards, LVT.


rrrrrr ©   (19.08.17 16:25[66]

знаешь, все эти капризы конечно очень элегантны и гламурны.

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

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


rrrrrr ©   (19.08.17 16:28[67]

плюс три дня трендеть на тему плёвой задачки уровня школьного кружка погромирования - это как бы роскошь а не средство движения вперед.
тоже имхо конечно


Eraser ©   (22.08.17 05:36[68]


> Denchik   (17.08.17 16:54) 

автор, тебе тут правильно несколько раз намекнули. все упирается в hdd/ssd.
даже два потока приведут к значительной деградации скорость, по сравнению с одним. почитай где-нибудь как hdd устроен. с SSD конечно легче, но не намного, ну 2-3 потока максимум, и то, тестировать надо.


Страницы: 1 2 3 4 версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо