Здравствуйте, уважаемыее! Мы решили возобновить публикации еще до окончания больших праздников, но в сегодняшней статье все-таки раскрыта тема справедливой раздачи подарков. Сама же статья, как понятно из названия, посвящена сравнительному анализу параллелизма и конкурентности.
Рубрика «concurrency» - 8
Parallelism vs Concurrency: правильно подбираем инструменты
2016-01-05 в 18:10, admin, рубрики: concurrency, Erlang/OTP, Go, haskell, parallelism, Rust, stm, Блог компании Издательский дом «Питер», высокая производительность, параллельное программирование, производительность, метки: parallelismЛегковесные потоки в Java
2015-04-08 в 9:01, admin, рубрики: concurrency, java, параллельное программированиеМногопоточная модель программирования предоставляет удобную абстракцию для разработки параллельных программ. К сожалению, большие накладные расходы потоков операционной системы на память и переключение контекстов сильно ограничивают их применение. Легковесные (прикладные, пользовательские) потоки не имеют таких проблем, так как требуют значительно меньше памяти и гораздо меньше нагружают процессор при переключении контекстов, что позволяет запустить большое количество таких потоков в приложении. Также легковесные потоки позволяют разрабатывать асинхронные приложения без использования обратных вызовов, что делает код чище и проще для понимания.
Потоки Java соответствуют потокам ядра и поэтому обладают всеми присущими им недостатками. В сети можно найти проекты, целью которых является отказ от потоков Java и реализация пользовательских потоков. Самые известные перечислены ниже.
Kilim — один из первых «рабочих» проектов, реализующих легковесные потоки. Библиотека предоставляет средства для создания приложений, основанных на обмене сообщениями. Из-за соответствующего API данную библиотеку можно рассматривать скорее как реализующую модель акторов, чем потоковую модель.
Quasar — другой проект, реализующий прикладные потоки, называемые нитями (fibers). Кроме легковесных потоков библиотека предоставляет построенную на нитях реализацию модели акторов. Хотя API нитей похож на API потоков Java, чтобы воспользоваться средствами библиотеки, потребуется переписать код приложения.
В данной статье рассматривается проект Zephyr. Его отличие от первых двух проектов заключается в том, что средства библиотеки позволяют «превратить» обычные потоки в легковесные, не изменяя кода приложения. В действительности библиотека позволяет использовать любую реализацию потоков, и легковесные потоки являются одной из возможных реализаций.
Читать полностью »
Concurrency: 6 способов жить с shared state
2014-03-17 в 8:26, admin, рубрики: actor model, concurrency, java, lock-free, locking, stm, Программирование, метки: actor model, concurrency, java, lock-free, locking, stm 
В многопоточном программировании много сложностей, основными из которых являются работа c разделяемым состоянием и эффективное использование предоставляемых ядер. Об использовании ядер пойдет речь в следующей статье.
С разделяемым состоянием в многопоточной среде существуют два момента, из-за которых возникают все сложности: состояние гонки и видимость изменений. В состоянии гонки, потоки одновременно изменяют состояние, что ведет к недетерменированному поведению. А проблема с видимостью заключаются в том, что результат изменения данных в одном потоке, может быть невидим другому. В статье будут рассказаны шесть способов как бороться с данными проблемами.
Все примеры приведены на Java, но содержат комментарии и я надеюсь будут понятны программистам не знакомым c Java. Данная статья носит обзорный характер и не претендует на полноту. В то же время она наполнена ссылками, которые дают более подробное объяснение терминам и утверждениям.
F.A.Q. по Java-конференции JPoint 2014
2014-02-19 в 3:54, admin, рубрики: concurrency, hibernate, java, jpoint, jvm, Блог компании CodeFreeze, метки: concurrency, hibernate, java, jpoint, jvm«Эпиграф
Конференция JPoint — реальный явский хардкор, по локоть в кровище.
Дима Завалишин, http://dz.livejournal.com/878711.html
Что? Где? Когда?
В пятницу, 18 апреля, в Москве пройдёт Java-конференция JPoint для Middle/Senior-разработчиков. В программе — доклады от ведущих специалистов, представляющих компании Oracle, Одноклассники, Deutsche Bank, JetBrains, Devexperts и др.
IdBasedLocking
2014-01-29 в 12:27, admin, рубрики: concurrency, java, lock, locking, locks, Веб-разработка, многопоточное программирование, многопоточность, Программирование, метки: concurrency, lock, locking, locks, многопоточное программирование, многопоточностьУ Java отличная поддержка параллелизма (concurrency) и блокировки (locking) — возможно, самая лучшая из тех, что предлагают современные языки. Кроме того, что в самом языке есть встроенная поддержка синхронизации, существует целый ряд полезных утилит на основе AQS framework. К ним относятся CountDownLatches, Barriers, Semaphores и прочие. Однако часто встречается ситуация, не поддерживающаяся напрямую: когда надо блокировать доступ не к конкретному объекту, а к идее этого объекта.
Высокопроизводительный SUN/ONCRPC сервер на Java NIO
2013-10-27 в 19:14, admin, рубрики: concurrency, grizzly, java, nio, высокая производительность, Программирование, метки: concurrency, grizzly, java, nioВ статьe о dCache рассказано о том, как использовать его в качестве NFS сервера. Но функциональной совместимости с существующими клиентами недостаточно, чтобы системой можно было пользоваться. Производительность тоже должна быть на высоте. Рабочей лошадкой NFS протокола является ONCRPC протокол. В dCache мы используем собственную реализацию, основанную на grizzly nio framework.
Немного истории для молодых
ONC RPC (Open Network Computing Remote Procedure Call) — протокол, созданный Sun Microsystems в конце 80х и опубликован в 1995г вместе с NFSv2. ONCRPC получил быстрое распространение и широко использовался, пока в начале 2000 не был вытеснен модными альтернативами, как CORBA, SOAP, а позже REST и JSON-RPC. Тем не менее, ONCRPC всё ещё используется, где простота и скорость важнее моды — в сетевых файловых системах.
Реализация
Чтобы не изобретать очередной велосипед, вначале мы использовали реализацию Remote Tea, но вскоре столкнулись с ограничениями, которые не могли легко решить: IPv6, GSSAPI, NIO. Так что велосипед пришлось изобретать, но не с нуля. Мы максимально сохранили совместимость с RemoteTea и адаптировали уже написанный код.
Преобразование асинхронных методов в синхронные с возвращением результата в Java
2013-06-01 в 9:32, admin, рубрики: concurrency, java, threads, Песочница, Программирование, метки: concurrency, java, threadsВ данной статье я бы хотел обсудить с уважаемым сообществом методы синхронизации потоков в Java. Чтобы не увязать в теории, попробуем рассмотреть синхронизацию потоков в задаче преобразования асинхронных методов в синхронные.
Дано
- JavaSE 6+
- библиотека с асинхронным методом
void A.asyncMethod(Callback callback);
- метод, который нужно переопределить, и вернуть из него результат
@Override
Object overridenMethod() {
return syncMethod();
}
Задача
Преобразовать асинхронный вызов метода в синхронный с возвращением результата.
Failsafe resource allocator over DHT
2013-04-17 в 19:49, admin, рубрики: api, big data, concurrency, DHT, метки: concurrency, DHTУ нас есть некоторый диапазон чисел от 0 до N, надо написать две функции int alloc() и free(int). Первая выбирает один из свободных идентификаторов из диапазона [0, N), а вторая соответственно — «возвращает» его для повторного использования(полагаем, что число N достаточно мало, что бы идентификаторы могли закончится если их не возвращать, но больше чем число выделенных в каждый конкретный момент времени идентификаторов). При этом на «нижнем уровне» у нас есть только DHT. Нету блокировок, и, кроме того, от алгоритмов требуется отказоустойчивость — если какой-то из узлов кластера «сложится» во время выполнения алгоритма поведение системы должно быть предсказуемо. Если задача интересна, а также интересно узнать почему отказоустойчивый сервис с такой сигнатурой невозможно корректно использовать, и как надо исправить сигнатуру что бы это стало возможно — добро пожаловать под кат.
Java: executor с уплотнением по ключам
2013-03-11 в 7:24, admin, рубрики: concurrency, data structures, java, multithreading, метки: concurrency, data structures, java, multithreading 
Существует типичная проблема в большом классе задач, которая возникает при обработке потока сообщений:
— нельзя пропихнуть большого слона через маленькую трубу, или другими словами, обработка сообщений не успевает «проглотить» все сообщения.
При этом существуют некоторые ограничения на поток данных:
- поток не равномерный и состоит из событий разного типа
- количество типов событий заранее не известно, но некоторое конечное число
- каждый тип события имеет свою актуальность во времени
- все типы событий имеют равный приоритет
На диаграмме приведён пример разрешения проблемы: нагребатор(tm), работающий на нитке T1, в то время как разгребатор(tm) работает на нитке T2
- за время обработки события типа A успевают прийти новые события как типа B, так и A
- после обработки события типа B необходимо обработать наиболее актуальное событие типа A
Т.о. стоит задача о выполнении задач по ключу, так, что выполняется только самая актуальная из всех задач по данному ключу.
На суд публике представляется созданный нами ThrottlingExecutor.
Замечание терминологии: stream есть поток данных, тогда как thread есть нитка или нить выполнения. И не стоит путать потоки с нитками.
Замечание 1: проблема осложняется ещё тем, что может быть несколько нагребаторов(tm), при этом каждый нагребатор(tm) может порождать только события одного типа; с другой стороны есть потребность в нескольких (конечно же, для простоты можно выбрать N=1) разгребаторах(tm).
Замечание 2: мало того, что данный код должен работать в многопоточной (конкурентной) среде — т.е то самое множество нагребаторов(tm) — разгребаторов(tm), код должен работать с максимальной производительностью и низкими latency. Резонно к этим всем качествам добавить ещё и свойство garbage less.
И почти в каждом проекте так или иначе возникает эта задача, и каждый её решает по разному, но все они либо не эффективны, либо медленны, либо и то, и другое вместе взятое.
Пятничная история про synchronized-методы в классе Thread
2013-02-15 в 20:52, admin, рубрики: concurrency, java, метки: concurrency, java Недавно я наткнулся на интересную особенность синхронизации на классе Thread. Я создал класс, наследующий Thread и использовал в нем паттерн lock object для внутренней синхронизации. В какой-то момент мне показалось что lock object раздувает код, а поскольку созданный поток я использую из очень малого числа мест, я его выкинул, заменив на synchronized методы и wait/notify на this. Если хотите знать, что из этого маленького нарушения «кодекса» вышло — добро пожаловать под кат.
Читать полностью »