crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Boost thread - ограниченное количество потоков?
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Stranger Дата 21.5.2009, 17:17
 
Цитата(Влад @ 23.3.2009, 22:27) *
Iron Bug, вот я прочел и так и не понял: зачем все-таки плодить такое колоссальное количество потоков? Тем более, что 99.9% постоянно будут в состоянии ожидания, а когда же им дадут чуток поработать....
Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров), и - баааальшая такая очередь заданий, которую они будут трудолюбиво разгребать. Как-то так.......
А при 2000 потоков они в основном будут бесполезно кушать ресурсы процесса, не успевая сделать ничего полезного.
Нет?
Litkevich Yuriy Дата 24.3.2009, 3:04
 
Цитата(ViGOur @ 24.3.2009, 2:52) *
Возьмем в качестве примера конвейер по сборке автомобиля, в нем множество независимых механизмов, которые выполняют свою работу, но должны быть синхронизированны между собой.
такую синхронизацию, на одном компьютере не делают, по моему опыту промавтоматики. И мне приходилось реализовывать подобные системы - компьютера в них небыло совсем.
ViGOur Дата 23.3.2009, 23:52
 
Цитата(Andrew Selivanov @ 23.3.2009, 18:52) *
Я для себя пришёл к выводу, что поддерживать КП без очень, очень веских на то причин - жутко затратная штука. Оттестил там - здесь отвалилось. Оттестил здесь - там отвалилось.
Не согласен. Если придерживаться стандартов и не привязываться к API, то все будет отлично. Если привязываться, то сложности в основном в планировании как и что будет работь.

Цитата(Влад @ 23.3.2009, 22:27) *
Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров),
Как я понял у Iron Bug множество независимых железок, которые должны работать индивидуально и не запороть работу других.

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

Iron Bug поправь меня если я тебя не правильно понял.
Влад Дата 23.3.2009, 22:27
  Iron Bug, вот я прочел и так и не понял: зачем все-таки плодить такое колоссальное количество потоков? Тем более, что 99.9% постоянно будут в состоянии ожидания, а когда же им дадут чуток поработать....
Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров), и - баааальшая такая очередь заданий, которую они будут трудолюбиво разгребать. Как-то так.......
А при 2000 потоков они в основном будут бесполезно кушать ресурсы процесса, не успевая сделать ничего полезного.
Нет?
Andrew Selivanov Дата 23.3.2009, 18:52
 
Цитата(Iron Bug @ 23.3.2009, 10:14) *
To Andrew Selivanov:
Руссинович у меня есть, но действительно довольно мутная книжка, сложно там что-то найти. Рихтер тоже ничего, гораздо более читабельно. Собственно, у меня вопросов-то почти не возникает, я под венду очень давно пишу. Про потоки в венде я и так знаю всё. Я и дрова для железа под неё писала, и сервисы, и всякие приблуды для юзеров, и всё, что только можно... Ну, архитектура у неё... эээ... КХМ... короче говоря, венда и есть венда! У компании пока по некоторым причинам нет планов переходить на линюкс, хотя давно пора уже! Мешает куча наработок и боязнь перехода. Собственно, планы всегда горят и особо времени нет, а кадров вечно не хватает... И вот сейчас у меня есть идея перейти на кроссплатформу и окончательно избавиться от мелкософтовских библиотек, что я уже успешно сделала в первом приближении. Но, как всегда бывает, сначала система была простой и логичной, но потом по требованиям юзеров обрастала всё новыми и новыми фичами, которые надо было городить срочно и которые всё хуже и хуже увязывались с изначально поставленными задачами... И вот программа превратилась в монстра, обвешанного костылями и стала ненадёжно работать. Поэтому я сейчас вот измышляю универсальную и стройную систему, чтобы учесть те требования, которые на данный момент существуют и, по возможности, предусмотреть возможность для безболезненной модификации при необходимости внесения новых фич. Более того, я замышляю линюксовый переворот хотя бы в области тестирования. Хочу попробовать написать пару дров и полностью протестировать работу машин под линём. Естессно, с демонстрацией преимуществ линюкса начальству! :) Я знаю, что я фанат, но тут ничего не поделать.

Про винду
Виндовая архитектура это вообще сплошные holy wars... Там поколения программистов оставили свои следы.

Про юзеров
Где то когда-то прочитал, что если просят ругаются и приносят баги - значит пользуются. Это хорошо :) Плохо, когда месяц трахался и "А.. спасибо" и - тишина...

Про костыли, горящие планы
Как знакомо :) Очевидно это у всех - следовательно - нормально.

Про кроссплатформу
Я для себя пришёл к выводу, что поддерживать КП без очень, очень веских на то причин - жутко затратная штука. Оттестил там - здесь отвалилось. Оттестил здесь - там отвалилось. Скачиваешь какой нибудь Open Source, вроде как КПный, а одна из версий - эммм... датирована годом эдак прошлым. Мягко говоря :)

Про C
Очевидно C++ :)

Про рефакторинг
Сам им страдаю периодически. Очень помогает изучение всякого качественного Open Source-a. Последнее время часто зависаю в коде DC++. Хорошая штука. А как там сделан протокол, автор мог бы статью отдельную написать. На радость разработчикам. Правда я не уверен, кто автор концепции.

Про Perl
Я его для себя воспринимаю как "Всё то, что бы хотели сделать в CMD, но не могли". СтОит потратить немного времени и понять про массивы, хэши, сокеты и прочее. IMHO.

Ударились во флейм и ушли от темы :) Думаю пора двинуть в специализированный раздел.
Iron Bug Дата 23.3.2009, 15:23
  ну, тут много деталей... если даже виртуальная машина и быстрая (что, мягко говоря, сомнительно) - то как её связать с реальным железом, у которого может не быть стандартных драйверов и стандартных интерфейсов? боюсь, что тут гемора будет выше крыши. хотя вычислений у меня не так много и они простые, зато надо постоянно и шустро парсить поток байтов с драйвера и вылавливать из него нужные данные. так что тут задача довольно специфическая. вообще, к телекому это отношения не имеет: это обработка данных от специально разработанного железа и управление точной механикой на очень большой скорости. то есть, автоматизация промышленных процессов. сетевого взаимодействия на уровне тестирования просто нет. все данные льются по спецшинам и ДМА в корзину, где и обрабатываются. довольно специфическая задача, со своими требованиями.
что касается Эрланга... я бегло просмотрела в сети отзывы народа про него... судя по отзывам, Эрланг вроде как не используется для таких задач, как у нас. что он быстрее С# - ну дык... гы! меня шарп вообще не интересует ни с какой стороны, ибо дикие тормоза и чисто прикладная реализация, в принципе не рассчитанная на низкоуровневую работу с железом. для стандартных интерфейсов это может быть и проканает, но очень маловероятно, что в него можно внедрить работу с межпроцессным адресным пространством, различными системными объектами и фреймами ДМА в памяти. отзывы в плюс Эрлангу - в основном по объёму кода. но мне совершенно фиолетово на объём - мне не лень писать код, лишь бы он работал быстро и надёжно. конечно, оптимизация может быть во всём, но объём кода тут на самом последнем месте. к тому же всякие автоматические сборки мусора напрягают сразу: это означает фактическую непредсказуемость работы системы. я думаю, если в промышленной автоматизации и системном программировании никто за столько лет не написал ничего на таких языках - то это неспроста. так что я всё же придерживаюсь программирования на Си: простой и надёжный язык, на нём можно написать всё, что только захочется. а про Эрланг - ну, если появится время, можно будет глянуть спецификацию более детально. однако пока что мне кажется, что он не подходит для моих задач.
Tonal Дата 23.3.2009, 12:42
  Erlang таки не скрипт а виртуальная машина. Заточенная специально под телеком и довольно производительная (soft real-time). Процессы у ей свои, легковесные, поэтому их можно запустить гораздо больше и быстрее чем потоках в винде или линухе.
К тому же есть стандартный биндинг с wxWidgets, так что мордочку можно и старую сохранить. :)
Ежели тяжелых вычислений нет, то вполне может покатить.

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

Да, про python: привязать его куда угодно вполне просто - очень вменяемый апи для расширений.
Ну и своих библиотек море. И IPC, и wxWidgets, и XML :)
Iron Bug Дата 23.3.2009, 10:14
  To Andrew Selivanov:
Руссинович у меня есть, но действительно довольно мутная книжка, сложно там что-то найти. Рихтер тоже ничего, гораздо более читабельно. Собственно, у меня вопросов-то почти не возникает, я под венду очень давно пишу. Про потоки в венде я и так знаю всё. Я и дрова для железа под неё писала, и сервисы, и всякие приблуды для юзеров, и всё, что только можно... Ну, архитектура у неё... эээ... КХМ... короче говоря, венда и есть венда! У компании пока по некоторым причинам нет планов переходить на линюкс, хотя давно пора уже! Мешает куча наработок и боязнь перехода. Собственно, планы всегда горят и особо времени нет, а кадров вечно не хватает... И вот сейчас у меня есть идея перейти на кроссплатформу и окончательно избавиться от мелкософтовских библиотек, что я уже успешно сделала в первом приближении. Но, как всегда бывает, сначала система была простой и логичной, но потом по требованиям юзеров обрастала всё новыми и новыми фичами, которые надо было городить срочно и которые всё хуже и хуже увязывались с изначально поставленными задачами... И вот программа превратилась в монстра, обвешанного костылями и стала ненадёжно работать. Поэтому я сейчас вот измышляю универсальную и стройную систему, чтобы учесть те требования, которые на данный момент существуют и, по возможности, предусмотреть возможность для безболезненной модификации при необходимости внесения новых фич. Более того, я замышляю линюксовый переворот хотя бы в области тестирования. Хочу попробовать написать пару дров и полностью протестировать работу машин под линём. Естессно, с демонстрацией преимуществ линюкса начальству! :) Я знаю, что я фанат, но тут ничего не поделать.
To Tonal:
Насчёт скриптов... Железки не независимы! Они как раз представляют собой единый очень сложный механизм. И процессы и потоки активно взаимодействуют в риал-тайме... И ещё юзер вмешивается до кучи. И надо проверять что все ответы от девайсов приходят, и чтобы юзера куда-нибудь не зажевало случайно, и чтобы железяки не запороли друг друга и ещё команды подавать, чтобы всё это бодро шевелилось :) Скрипты - хорошая вещь для мелких задач. А у меня задачи объёмистые и надо ещё юзерский интерфейс городить. Тестирую, естественно, не я, а те люди, которые занимаются разработкой механики. Так что нужен простой и понятный полновесный графический интерфейс, а не просто запуск из командной строки. Пользователь задаёт кучу параметров, запускает различные тесты и может контролировать отдельные устройства и управлять или в ходе теста вручную. Кроме того, пользователь работает с механической частью, что тоже надо контролировать - во избежание. Всё это происходит без помощи программиста и рассчитано на людей, которые к программированию отношения не имеют. У меня интерфейс написан - из XML в wxWidgets генерит морды и подключается к межпроцессным очередям сообщений. Эта часть отработана. Я подозреваю, что скрипты привязать к межпроцессному обмену под вендой сложновато будет. К тому же, на Си я пишу с детства, со времён ДОСа и первого борландовского компилятора :), питоном я вообще никогда не интересовалась, а в перл я дальше регекспов не лазила.
Так что пока буду стремиться к совершенству на Си. А по ночам я один фиг не сплю, даже если программировать ничего срочно не надо - я не контрабасе играю на радость соседям :)
Tonal Дата 21.3.2009, 10:06
  Ежели железки тестируются независимо, то действительно почему бы не взять какой-нибудь нормальный скриптовый язык, Python, например.
И запускать по процессу на каждую железячку?
Думаю тот же linux 2000 python процессов выдержит без труда. :)

Ежели что-то более сложное - можно erlang посмотреть - вроде самое оно. :)
Andrew Selivanov Дата 20.3.2009, 16:18
  Ааа.. стало яснее, но картину в целом всё равно представить сложно :)
Я обычно всё что связано с тестированием или срочно проверить итп ваяю на Perl-e. Очень удобно.

<тупые советы>
Кстати лучше ночью спать. Еще банальность - совершенство недостижимо ;) Еще банальность - чем проще тем лучше.
</тупые советы>

На самом деле для внутренностей винды наиболее авторитетное и объемное издание это Сломон/Руссинович "Internals..." Хотя искать там что-то сложновато да и есть не всё. Но тем не менее.
Там довольно хорошо раскрыта тема потоков.

И ещё я тут подумал - есть ли вообще смысл в многопоточной модели в твоём случае? Ведь реальных ядер всего (два, четыре, восемь) а потоков - куча. Будет много переключений контекста. Не проще ли взять нечто вроде Reactor-а ( http://www.cs.wustl.edu/~schmidt/PDF/reactor-rules.pdf ) и контролировать взаимодействие самому..?
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 28.3.2024, 23:43