Описание функций класса Thread

[mazzy]

Хм... уважаемые участники... все участники... см. правила, пункт 2
http://www.axforum.info/forums/showt...postid=13070#2

Цитата:

Изначально опубликовано Maxim Gorbunov
Уже почти с Вами согласен. Однако, как показывает практика, потоки использовать для параллельной записи в базу не есть хорошо. Уж лучше использовать пакетный сервер. Хотя бы потому, что он по построению системы имеет более толстый канал связи с СУБД.

Какие задачи Вы решаете с помощью отдельных потоков?

На основе чеог был сделан вывод о толщине канала связи с БД?
2macklakov. Покупать ничего не надо все давно установлено: см. WinAPI. Что считать проблемным потоком это наверное отдельный вопрос. Вопрос как определить проблемный поток тоже несложный, решается на основе данного ранее материала.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано lagr221374

На основе чеог был сделан вывод о толщине канала связи с БД?

См. Microsoft Axapta Deployment, ищите Planning Batch Server.

я имею ввиду потоки

там разве есть сравнение?

[Maxim Gorbunov]

Сравнение чего с чем?

Поток имеет смысл выполнять на клиенте.
Если синхронизацию проводить через БД - это постоянный обмен данными через канал.
Канал у клиентов по определению тонкий.

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

[macklakov]

Цитата:

Изначально опубликовано lagr221374
2macklakov. Покупать ничего не надо все давно установлено: см. WinAPI. Что считать проблемным потоком это наверное отдельный вопрос. Вопрос как определить проблемный поток тоже несложный, решается на основе данного ранее материала.

Если не покупать, то придется писать свой инструмент, т.к. WinAPI лишь предоставляет возможность, но не реализует ее.

Почему? Разгон клиента сродни разгону танкиста в танке (много не выиграешь, даже если заставишь и механика и радиста танк подталкивать, толку мало, а сдохнут точно очень быстро). Если же поставить в танк второй двигатель может и помочь.
2macklakov. WinAPI был специально создан чтоб народ в виде программистов не парился над глобальными проблемами

[Maxim Gorbunov]

Не, аналогию Вы не поняли.

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

В общем, потоки, это лишь способ заполнить время простоя. Если у Вас большое время простоя сервера и большие пиковые нагрузки, планируйте сетевую архитектуру решения: вводите пакетные сервера, кластеры AOS и т. п.
У клиентской машины время простоя может быть велико. Использование потоков - один из способов это время занять.

[macklakov]

Цитата:

Изначально опубликовано lagr221374
2macklakov. WinAPI был специально создан чтоб народ в виде программистов не парился над глобальными проблемами

Весьма познавательно, но мы плаваем мелко и решаем приземленные проблемы. Какова, по вашему мнению, трудоемкость создания инструмента, позволяющего администратору наблюдать и гасить проблемные потоки?
P.S. возникнуть они могут из-за глюка на сервере даже у идеального программиста

Разработка механизма убийства потока занимает у программиста максимум 4 часа (с учетом доступа к MSDN). Механизм наблюдения + 4 часа

[macklakov]

Цитата:

Изначально опубликовано lagr221374
Разработка механизма убийства потока занимает у программиста максимум 4 часа (с учетом доступа к MSDN). Механизм наблюдения + 4 часа

Т.е. если брать по минимуму, то 8 * ~$30 = $240 + время на отладку и документирование ~$600. Ну что ж, не так уж и разорительно. Даже немного дешевле, чем отдельная лицензия под пакетный обработчик.

Размещение нагрузки на клиента редкое извращение на мой личный взгляд при 3-х звенке (опять же исходя из теории). По-моему Axapta это декларирует так как не смогла перенести всю тяжесть работы на первые два сегмента и задекларировала уникальность: перенос нагрузки на клиента, что по-моему личному мнению неправильно.
2 Нагрузка на процессор в среднем чуть выше половины (по опять же личному опыту, возможно при Axapta это не так но сомнения)

[Maxim Gorbunov]

Поработайте с Аксаптой.

Некоторые задачи имеет смысл выполнять на клиентской машине (в основном, связанные с интерфейсом и разработкой). Для них, возможно, и следует приспособить потоки. Остальные задачи прекрасно решаются без них.

Ну вот приехали... И все в Axapta замечательно. с тем что на клиенте должен быть только интерфейс в идеале никто не спорит.
Решаются ли остальные задачи прекрасно? Наверное нет, если приходиться прибегать к пакетникам и т.п. Лучше ли поток чем пакетник, наверное да но он мало изучен. Поэтому и возникло предложение сообщить кто-что знает.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано lagr221374
Лучше ли поток чем пакетник, наверное да

Откуда такая уверенность?
ИМХО, потоками пакетный сервер заменять не стоит. Это решение из серии "голь на выдумки хитра". Заведите себе нормальный пакетный сервер и не пытайтесь открыть Америку.

[George Nordic]

Стоп-стоп-стоп!

Дело не в том, кто и как извращается. Был вопрос - какие могут быть проблемы?
Что-то не вижу никакого конструктива. Да, пакетник-хорошо, потоки-плохо. Однако, есть часть задач, для которых использование потоков - отличное решение.
Допустим, чтение данных из СОМ-порта.
На клиенте, разумеется!

С Уважением,
Георгий.

2Максим Выше я уже объяснял свои цели, задачи, соответственно...внимательно смотрите предыдущий текст.

[Maxim Gorbunov]

Резюме (lagr не хочет делать, сделаю сам - мы не гордые ):

Из проблем, которые могут возникнуть при работе с потоками, названы следующие:
1. Отсутствие механизмов синхронизации потоков.
2. Проблемы с администрированием потоков.

От себя замечу, что очень сильно затрудняет решение этих вопросов тот факт, что в порождаемый Thread нельзя передать объект.

[macklakov]

И вот что любопытно, если серверные потоки нас не интересуют, то пакетный обработчик практически ничем не отличается от потоков. С помощью минимальных доработок, в пакетном обработчике можно скрыть все служебные окна, которые раздражают пользователей, при входе запускать режим пакетного сервера и это превосходно подходит для решения служебных задач в фоновом режиме При этом имеется готовый инструмент, для планирования заданий и контроля их исполнения.