Комментарии 20
Интересно, почему на Хабре пруд пруди вот таких выдержек из любого учебника по ЯваСкрипту, Питону, Руби и Андроиду, но практически нет по Яве и Си?
я не понял — вы «за» или «против»?
А вы прикиньте процентное соотношение профессионалов на Си и на Яве.
Я думаю процентное соотношение в рамках каждой платформы примерно одинаково. Людей, которые по-настоящему знают Java / количество java разработчиков примерно равно аналогичной пропорции для С.
Принцип Парето? :-)
В С++ сейчас столько наворотили, что специалистов, которые все это знают, становится все меньше. Один мой друг много лет программировал на С++ и WinAPI и даже выигрывал конкурсы Intel — решил как-то раз сдать собеседование в захудалой провинциальной конторе по С++. И не сдал!!! Просто закидали какими-то терминами и закопали буквами. Зато в Интел его взяли без проблем, так как приложения, которые они пишет выигрывают конкурсы.
Вот только вчера вечером закончил реализацию небольшой библиотеки для многопоточности на С++ для одного кроссплатформенного фреймворка. Класс может работать как автономно, так и использовать пул потоков. Кроме того, в нём есть конвейер на основе очереди исполнения, который сильно уменьшает необходимость в объектах синхронизации, а в простых случаях делает их и вовсе ненужными. И всё это работает стабильнее, и прочее, и прочее.
Я бы с радостью поделился и кодом, и идеями с народом, с радостью бы выслушал критику. Но где взять время для написания статей?.. Всё делается в спешном порядке, для очередных проектов. Нет возможности даже нормально ответить по комментариям к предыдущим статьям.
Я бы с радостью поделился и кодом, и идеями с народом, с радостью бы выслушал критику. Но где взять время для написания статей?.. Всё делается в спешном порядке, для очередных проектов. Нет возможности даже нормально ответить по комментариям к предыдущим статьям.
вопрос в том, зачем нужны такие выдержки.
Первоначальная задача «как организовать многопоточность». Мы идем в гуголь, набираем стандартный шаблон «технология+предметная область+способ реализации», в данном случае «Java Multithreading Framework» и получаем Executor в первой строчке поиска.
ОК, допустим, первоначальная задача решена, и мы прибежали на Хабр в поисках деталей использования Executor'а. Но мы видим вырезку, ничем не более информативную, чем еще 100500 постов в блогах на ту же самую тему, не рассказывающую ничего нового по сравнению даже с тем же жавадоком по Executor'у.
Знаете, одно время продавались толстые книги про Яву и Си, которые ничем не отличались от жавадока. Поэтому их никто не читал и не покупал. Наверное поэтому они потихоньку перевелись совсем ;)
Я за, но в статью нужно срочно вставить изюминку!
Первоначальная задача «как организовать многопоточность». Мы идем в гуголь, набираем стандартный шаблон «технология+предметная область+способ реализации», в данном случае «Java Multithreading Framework» и получаем Executor в первой строчке поиска.
ОК, допустим, первоначальная задача решена, и мы прибежали на Хабр в поисках деталей использования Executor'а. Но мы видим вырезку, ничем не более информативную, чем еще 100500 постов в блогах на ту же самую тему, не рассказывающую ничего нового по сравнению даже с тем же жавадоком по Executor'у.
Знаете, одно время продавались толстые книги про Яву и Си, которые ничем не отличались от жавадока. Поэтому их никто не читал и не покупал. Наверное поэтому они потихоньку перевелись совсем ;)
Я за, но в статью нужно срочно вставить изюминку!
Так можно прийти к выводу, что любой текстовый материал по стандартной библиотеке вторичен по сравнению с самой стандартной библиотекой :) (Вместо жавадока, кстати, зачастую реально удобнее исходники jdk смотреть :) Задача — ускорить освоение, нигде не наврав и не потеряв смысл. Если есть изюминка — так совсем замечательно.
В свое время пару лет назад «пересаживал» один проект с «голых» потоков (wait(), notifyAll()) на java.util.concurrent. Не пожалел ни минуты потраченного времени — код стал гораздо чище, понятнее другим разработчикам (особенно тем, кто только-только приходил в проект), а самое главное — избавились от всех дедлоков и лайвлоков.
Так что всем, кто до сих пор увяз в старом конкурентном коде, я настоятельно советую посмотреть хотябы в сторону j.u.c (а лучше — Clojure и/или Akka).
Тем, кто по какой-то причине не может перейти на Java 5 (да, знаю полно таких мест), напоминаю, что есть вполне рабочий и проверенный временем бэкпорт: backport-jsr166.sourceforge.net/
Так что всем, кто до сих пор увяз в старом конкурентном коде, я настоятельно советую посмотреть хотябы в сторону j.u.c (а лучше — Clojure и/или Akka).
Тем, кто по какой-то причине не может перейти на Java 5 (да, знаю полно таких мест), напоминаю, что есть вполне рабочий и проверенный временем бэкпорт: backport-jsr166.sourceforge.net/
Странно, что почти во всех примерах по многопоточности Java нет даже простых вычислений рациональности применения потоков.
типа int cores = Runtime.getRuntime().availableProcessors();
Может в одном потоке будет быстрее работать, так как не надо будет ждать блокировок
типа int cores = Runtime.getRuntime().availableProcessors();
Может в одном потоке будет быстрее работать, так как не надо будет ждать блокировок
Побуду немного кэпом. Причин использования многопоточности вагон и маленькая тележка и использование использование многопоточности для ускорения вычислений это одна из множества областей применения.
Простой пример предположим у тебя всего одно ядро. Есть основной поток, во время работы которого возникло событие о котором надо отправить отчет на удаленный сервер. Если ты все делаешь в одном потоке то пока программа подключится к удаленному серверу (а пинг иногда может и в сотнях мс измеряться) пока выгрузит данные, пока еще как то там отреагирует на событие. Все это время основной поток простаивает. А если еще есть проблемы со интенет соединением, то он будет пытаться еще несколько попыток отаравки сделать. Между которыми еще таймаут выждет. И все это время работа программы парализована. Поэтому мы создаем отдельный поток и обработку события выносим в отдельный поток. Все. Программа может дальше заниматься своими делами, а обработчик события может неспешно пытаться отправить этот файл на удаленный сервер. И даже несмотря на то, что у тебя всего навсего одно ядро, то есть ни о каком истинно паралельном вычислении быть не может. Но так как обработчик события все равно большую часть времени ждет выполнения операций ввода вывода, то никаких проблем это не создает и программа работает лучше.
Простой пример предположим у тебя всего одно ядро. Есть основной поток, во время работы которого возникло событие о котором надо отправить отчет на удаленный сервер. Если ты все делаешь в одном потоке то пока программа подключится к удаленному серверу (а пинг иногда может и в сотнях мс измеряться) пока выгрузит данные, пока еще как то там отреагирует на событие. Все это время основной поток простаивает. А если еще есть проблемы со интенет соединением, то он будет пытаться еще несколько попыток отаравки сделать. Между которыми еще таймаут выждет. И все это время работа программы парализована. Поэтому мы создаем отдельный поток и обработку события выносим в отдельный поток. Все. Программа может дальше заниматься своими делами, а обработчик события может неспешно пытаться отправить этот файл на удаленный сервер. И даже несмотря на то, что у тебя всего навсего одно ядро, то есть ни о каком истинно паралельном вычислении быть не может. Но так как обработчик события все равно большую часть времени ждет выполнения операций ввода вывода, то никаких проблем это не создает и программа работает лучше.
Что-то делать параллельно с каким-нибудь life lock — это почти единственный очевидный бенефит, если на deadlock не наступишь. Все остальное отягощено спецэффектами, коих миллион. Я пока на джаве делал параллельное выполнение, совмещенное с GUI — потратил кучу нервов, и так до конца не получилось без глюков обновлять картинку на форме, которая рисуется параллельно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многопоточность в Java: ExecutorService