Рубрика «concurrency» - 7

Добрый день, это «Без слайдов». В гостях у меня побывал Роман Елизаров, Java Champion, эксперт по Java и многопоточности (а с недавнего времени — еще и по финансовой математике), спикер многочисленных конференций, председатель жюри Северо-Восточного Европейского региона ACM-ICPC, престижнейшей в мире олимпиады по программированию, лектор в ИТМО и, наконец, VP по технологиям в компании Devexperts. В общем, «человек и пароход».

В разговоре мы затронули следующие темы:

  • что такое финансовая математика и как ее учить;
  • как устроен софт для финансовой индустрии;
  • как в компании Devexperts появилась исследовательская лаборатория по многопоточности;
  • куда развивается Concurrency, и что будет в моде в ближайшее время;
  • как всемирная олимпиада по программированию пришла в Россию.

Текстовая версия — под катом.
Читать полностью »

Предлагаю вам перевод статьи Gary Willoughby «Interesting ways of using Go channels».

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

gopher

Интересные способы использования Go каналов

Я написал этот пост, чтобы задокументировать доклад про Go каналы Джона Грэм-Камминга на конференции GopherCon 2014. Доклад назывался «Краткое руководство по каналам» и он доступен для просмотра на youtube.com.

На протяжении доклада нам представляют интересные способы использования Go каналов и раскрывают возможности и преимущества конкурентного программирования. Лично мне этот доклад открыл глаза на несколько новых способов структурирования программ и новых техник для синхронизации по нескольким ядрам процессора.

Следующие примеры демонстрируют различные техники, как использовать каналы в Go. Код был специально упрощен для их понимания. Не стоит его использовать для продакшн версий. Например, пропущены все обработки ошибок.
Читать полностью »

Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации нитей.

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).

Справочник по синхронизаторам java.util.concurrent.* - 1

Синхронизаторы – вспомогательные утилиты для синхронизации нитей, которые дают возможность разработчику регулировать и/или ограничивать работу нитей и предоставляют более высокий уровень абстракции, чем основные примитивы языка (мониторы).
Читать полностью »

Одной из самых сильных сторон языка программирования Go является встроенная поддержка concurrency, основанная на труде Тони Хоара «Communicating Sequential Processes». Go создан для удобной работы с многопоточным программированием и позволяет очень легко строить довольно сложные concurrent-программы. Но задумывались ли вы когда-нибудь, как выглядят различные паттерны concurrency визуально?

Конечно, задумывались. Все мы, так или иначе, мыслим визуальными образами. Если я попрошу вас о чём-то, что включает числа «от 1 до 100», вы мгновенно их «увидите» в своей голове в той или иной форме, вероятно даже не отдавая себе в этом отчёт. Я, к примеру, ряд от 1 до 100 вижу как линия с числами уходящая от меня, поворачивающая на 90 градусов вправо на числе 20 и продолжающая до 1000+. И, покопавшись в памяти, я вспоминаю, что в самом первом детском саду в раздевалке вдоль стены были написаны номерки, и число 20 было как-раз в углу. У вас же, вероятно, какое-то свое представление. Или вот, другой частый пример — представьте круглый год и 4 сезона года — кто-то их видит как квадрат, каждая грань которого принадлежит сезону, кто-то — как круг, кто-то ещё как-то.

Так или иначе, позвольте мне показать мою попытку визуализировать основные паттерны concurrency с помощью Go и WebGL. Эти интерактивные визуализации более-менее отражают то, как я вижу это в своей голове. Интересно будет услышать, насколько это отличается от визуализаций читателей.
Визуализация concurrency в Go с WebGL - 1
Читать полностью »

Здравствуйте, уважаемыее! Мы решили возобновить публикации еще до окончания больших праздников, но в сегодняшней статье все-таки раскрыта тема справедливой раздачи подарков. Сама же статья, как понятно из названия, посвящена сравнительному анализу параллелизма и конкурентности.

Читать полностью »

Многопоточная модель программирования предоставляет удобную абстракцию для разработки параллельных программ. К сожалению, большие накладные расходы потоков операционной системы на память и переключение контекстов сильно ограничивают их применение. Легковесные (прикладные, пользовательские) потоки не имеют таких проблем, так как требуют значительно меньше памяти и гораздо меньше нагружают процессор при переключении контекстов, что позволяет запустить большое количество таких потоков в приложении. Также легковесные потоки позволяют разрабатывать асинхронные приложения без использования обратных вызовов, что делает код чище и проще для понимания.

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

Kilim — один из первых «рабочих» проектов, реализующих легковесные потоки. Библиотека предоставляет средства для создания приложений, основанных на обмене сообщениями. Из-за соответствующего API данную библиотеку можно рассматривать скорее как реализующую модель акторов, чем потоковую модель.

Quasar — другой проект, реализующий прикладные потоки, называемые нитями (fibers). Кроме легковесных потоков библиотека предоставляет построенную на нитях реализацию модели акторов. Хотя API нитей похож на API потоков Java, чтобы воспользоваться средствами библиотеки, потребуется переписать код приложения.

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

concurrency

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

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

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

Читать полностью »

«Эпиграф

Конференция JPoint — реальный явский хардкор, по локоть в кровище.
Дима Завалишин, http://dz.livejournal.com/878711.html

Что? Где? Когда?

В пятницу, 18 апреля, в Москве пройдёт Java-конференция JPoint для Middle/Senior-разработчиков. В программе — доклады от ведущих специалистов, представляющих компании Oracle, Одноклассники, Deutsche Bank, JetBrains, Devexperts и др.

Читать полностью »

У Java отличная поддержка параллелизма (concurrency) и блокировки (locking) — возможно, самая лучшая из тех, что предлагают современные языки. Кроме того, что в самом языке есть встроенная поддержка синхронизации, существует целый ряд полезных утилит на основе AQS framework. К ним относятся CountDownLatches, Barriers, Semaphores и прочие. Однако часто встречается ситуация, не поддерживающаяся напрямую: когда надо блокировать доступ не к конкретному объекту, а к идее этого объекта.

Читать полностью »

В стать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 и адаптировали уже написанный код.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js