Pull to refresh
  • by relevance
  • by date
  • by rating

What's all this fuss about Erlang?

Erlang/OTP *
Translation
by Joe Armstrong

Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.

Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.

Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.

Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.

Хорошие новости для Erlang-программистов:

На N-ядерном процессоре ваша программа будет работать в N раз быстрее.

Читать дальше →
Total votes 77: ↑73 and ↓4 +69
Views 2.8K
Comments 271

Что такое транзакционная память и чем она полезна

Website development *
По мере того, как многоядерные процессоры получают все большее и большее распространение, умение писать программы, использующие все доступные процессоры становится все более и более важным. Давайте рассмотрим то, почему существующие широко используемые средства написания программ для многоядерных процессоров не достаточно хорошее решение, что такое транзакционная память, и как она решает указанную проблему.
Читать дальше →
Total votes 44: ↑41 and ↓3 +38
Views 5.3K
Comments 21

Многопоточность: в какую сторону думать

Java *
Змей-горыныч от Sun
Не так давно я по некоторому стечению обстоятельств принял участие в своеобразном соревновании, которое довольно быстро превратилось в исследование. Это исследование дало результаты, которые будут интересны читателям блогов Java и Алгоритмы в равной степени. По невозможности разместить сразу в двух местах, этот пост я решил разбить на две части. Как вам наверняка подсказывает Капитан, эта часть расскажет о результатах, касающихся Java.
Кстати, из исследовательской команды не только я зарегестрирован на Хабре: если хотите выразить благодарность, то не забывайте о markiz и icekeeper.
Читать дальше →
Total votes 56: ↑37 and ↓19 +18
Views 8.1K
Comments 29

PLINQ: распределение данных между рабочими потоками

.NET *
Пусть имеется некоторая последовательность элементов, которую мы хотим обработать при помощи PLINQ-запроса. При этом есть некоторое количество физических ядер CPU, готовых выполнять рабочие потоки. Как распределить элементы входной коллекции между потоками?
Читать дальше →
Total votes 34: ↑24 and ↓10 +14
Views 1.9K
Comments 5

java.util.concurrent. Часть первая: Зачем и почему?

Java *
Часть первая, в которой множеством слов раскрывается смысл существования этого API
Эта статья, хоть и не является прямым переводом, основана на статье Брайана Гетца Concurrency in JDK 5.0

Читать дальше →
Total votes 49: ↑39 and ↓10 +29
Views 26K
Comments 29

Новый синхронизатор Phaser

Java *
Tutorial
Phaser (Этапщик) — мощная и гибкая реализация паттерна синхронизации Барьер. Включен в JDK 7 в составе пакета java.util.concurrent.

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

Читать дальше →
Total votes 38: ↑37 and ↓1 +36
Views 47K
Comments 4

Конкурентность в асинхронном приложении на примере twisted

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

Но на практике все выглядит немного по иному:
Читать дальше →
Total votes 31: ↑27 and ↓4 +23
Views 3.7K
Comments 18

Java. Остановись задача

Java *
Sandbox
Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.
Читать дальше →
Total votes 58: ↑41 and ↓17 +24
Views 90K
Comments 29

Летняя школа Microsoft Research по параллельным вычислениям открывает регистрацию участников

Microsoft corporate blog
Во время летних каникул исследовательское подразделение компании Microsoft – Microsoft Research проводит ежегодное крупнейшее мероприятие, ориентированное на аспирантов, студентов старших курсов и молодых ученых – Летнюю Школу. В этом году школа будет проходить в Санкт-Петербурге в сотрудничестве с НИУ ИТМО с 22 по 29 августа 2012 года.



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

Тематика школы: параллельные вычисления (Concurrency and Parallelism in Software).
Читать дальше →
Total votes 23: ↑17 and ↓6 +11
Views 5K
Comments 3

Пишем кеш с определенным временем хранения объектов с использованием java.util.concurrent

Java *
Sandbox
Не так давно, мне выпала задача, написать кеш, который сам себя чистит по истечению некоторого определенного времени. Требования к нему были следующие:
  1. Легковесность
  2. Потокобезобасность

В общем-то и все. До написания данной задачи с java.util.concurrent дела не имел. На мысль использования этого пакета меня натолкнул один мой коллега, у которого было нечто подобное, но не соответствовало тому функционалу который был нужен. Итак, начнем:

В качестве ключа будет выступать внутренний класс, который помимо прямого назначения будет определять он является «живым» или его можно удалить с кеша, так как время его существования подошло к концу:
Читать дальше →
Total votes 29: ↑25 and ↓4 +21
Views 17K
Comments 24

А как же всё-таки работает многопоточность? Часть I: синхронизация

Java *System Programming *Concurrent computing *
Tutorial
картинка для привлечения внимания(пост из серии «я склонировал себе исходники hotspot, давайте посмотрим на них вместе»)
Все, кто сталкивается с многопоточными проблемами (будь то производительность или непонятные гейзенбаги), неизбежно сталкиваются в процессе их решения с терминами вроде «inflation», «contention», «membar», «biased locking», «thread parking» и тому подобным. А вот все ли действительно знают, что за этими терминами скрывается? К сожалению, как показывает практика, не все.

В надежде исправить ситуацию, я решил написать цикл статей на эту тему. Каждая из них будет построена по принципу «сначала кратко опишем, что должно происходить в теории, а потом отправимся в исходники и посмотрим, как это происходит там». Таким образом, первая часть во многом применима не только к Java, а потому и разработчики под другие платформы могут найти для себя что-то полезное.

Перед прочтением глубокого описания полезно убедиться в том, что вы в достаточной мере разбираетесь в Java Memory Model. Изучить её можно, например, по слайдам Сергея Walrus Куксенко или по моему раннему топику. Также отличным материалом является вот эта презентация, начиная со слайда #38.
Читать дальше. Много.
Total votes 130: ↑122 and ↓8 +114
Views 160K
Comments 21

Библиотека OmniThreadLibrary — простая многопоточность в среде Delphi

Programming *Delphi *Algorithms *
Написать интересную статью на техническую тему очень сложно. Приходится балансировать между тем, чтобы не скатиться в технические дебри и тем, чтобы совсем ничего не сказать. Сегодня я попробую в общих словах (без деталей) поговорить о том, как обстоят дела с разработкой многопоточных desktop-приложений в не столь популярной на сегодняшний день, но наверняка знакомой многим российским разработчикам среде Delphi. Статья ориентирована на НЕ новичков в программировании, являющихся при этом новичками в области создания многопоточных приложений.
Читать дальше →
Total votes 27: ↑24 and ↓3 +21
Views 26K
Comments 65

Обзор java.util.concurrent.*

Luxoft corporate blog Programming *Java *
Tutorial
В повседневной работе не так уж часто приходится сталкиваться с пакетом для многопоточности java.util.concurrent. Иногда существуют проектные ограничения по использованию java 1.4.2, где нет данного пакета, но чаще всего хватает обычной синхронизации и не требуется ничего сверхъестественного. К счастью, периодически возникают задачи, заставляющие немного пораскинуть мозгами и либо написать велосипед, либо порыться в javadoc'ах и найти что-то более подходящее. С велосипедом проблем нет — просто берешь и пишешь, благо ничего суперсложного в многопоточности нет. С другой стороны, меньше кода — меньше багов. Тем более, что на многопоточность никто в здравом уме юнит тестов не пишет, т.к. это уже полноценные интеграционные тесты получаются со всеми вытекающими последствиями.

Что выбрать для конкретного случая? В условиях запарки и deadline'ов довольно сложно охватить весь java.util.concurrent. Выбирается что то похожее и вперед! Так, постепенно, в коде появляются ArrayBlockingQueue, ConcurrentHashMap, AtomicInteger, Collections.synchronizedList(new LinkedList()) и другие интересности. Иногда правильно, иногда нет. В какой то момент времени начинаешь осознавать, что более 95% стандартных классов в java вообще не используются при разработке продукта. Коллекции, примитивы, перекладывание байтиков с одного места на другое, hibernate, spring или EJB, еще какая то библиотека и, вуаля, приложение готово.

Чтобы хоть как то упорядочить знания и облегчить вхождение в тему, ниже идет обзор классов для работы с многопоточностью. Пишу прежде всего как шпаргалку для себя. А если еще кому сгодится — вообще замечательно.
Читать дальше →
Total votes 96: ↑87 and ↓9 +78
Views 590K
Comments 33

Пятничная история про synchronized-методы в классе Thread

Java *
Недавно я наткнулся на интересную особенность синхронизации на классе Thread. Я создал класс, наследующий Thread и использовал в нем паттерн lock object для внутренней синхронизации. В какой-то момент мне показалось что lock object раздувает код, а поскольку созданный поток я использую из очень малого числа мест, я его выкинул, заменив на synchronized методы и wait/notify на this. Если хотите знать, что из этого маленького нарушения «кодекса» вышло — добро пожаловать под кат.
Читать дальше →
Total votes 19: ↑14 and ↓5 +9
Views 13K
Comments 9

Java: executor с уплотнением по ключам

Java *
Sandbox
image

Существует типичная проблема в большом классе задач, которая возникает при обработке потока сообщений:

— нельзя пропихнуть большого слона через маленькую трубу, или другими словами, обработка сообщений не успевает «проглотить» все сообщения.

При этом существуют некоторые ограничения на поток данных:

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


На диаграмме приведён пример разрешения проблемы: нагребатор(tm), работающий на нитке T1, в то время как разгребатор(tm) работает на нитке T2
  • за время обработки события типа A успевают прийти новые события как типа B, так и A
  • после обработки события типа B необходимо обработать наиболее актуальное событие типа A

Т.о. стоит задача о выполнении задач по ключу, так, что выполняется только самая актуальная из всех задач по данному ключу.

На суд публике представляется созданный нами ThrottlingExecutor.

Замечание терминологии: stream есть поток данных, тогда как thread есть нитка или нить выполнения. И не стоит путать потоки с нитками.

Замечание 1: проблема осложняется ещё тем, что может быть несколько нагребаторов(tm), при этом каждый нагребатор(tm) может порождать только события одного типа; с другой стороны есть потребность в нескольких (конечно же, для простоты можно выбрать N=1) разгребаторах(tm).

Замечание 2: мало того, что данный код должен работать в многопоточной (конкурентной) среде — т.е то самое множество нагребаторов(tm)разгребаторов(tm), код должен работать с максимальной производительностью и низкими latency. Резонно к этим всем качествам добавить ещё и свойство garbage less.

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

Читать дальше →
Total votes 39: ↑34 and ↓5 +29
Views 15K
Comments 66

Failsafe resource allocator over DHT

API *Big Data *
У нас есть некоторый диапазон чисел от 0 до N, надо написать две функции int alloc() и free(int). Первая выбирает один из свободных идентификаторов из диапазона [0, N), а вторая соответственно — «возвращает» его для повторного использования(полагаем, что число N достаточно мало, что бы идентификаторы могли закончится если их не возвращать, но больше чем число выделенных в каждый конкретный момент времени идентификаторов). При этом на «нижнем уровне» у нас есть только DHT. Нету блокировок, и, кроме того, от алгоритмов требуется отказоустойчивость — если какой-то из узлов кластера «сложится» во время выполнения алгоритма поведение системы должно быть предсказуемо. Если задача интересна, а также интересно узнать почему отказоустойчивый сервис с такой сигнатурой невозможно корректно использовать, и как надо исправить сигнатуру что бы это стало возможно — добро пожаловать под кат.

Читать дальше →
Total votes 11: ↑10 and ↓1 +9
Views 2.2K
Comments 0

Преобразование асинхронных методов в синхронные с возвращением результата в Java

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

Дано


  • JavaSE 6+
  • библиотека с асинхронным методом

void A.asyncMethod(Callback callback);

  • метод, который нужно переопределить, и вернуть из него результат

@Override
Object overridenMethod() {
	return syncMethod();
}


Задача


Преобразовать асинхронный вызов метода в синхронный с возвращением результата.

Читать дальше →
Total votes 15: ↑8 and ↓7 +1
Views 6.6K
Comments 39

Высокопроизводительный SUN/ONCRPC сервер на Java NIO

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

Подробности реализации
Total votes 13: ↑13 and ↓0 +13
Views 6.5K
Comments 0

А как же всё-таки работает многопоточность? Часть II: memory ordering

Java *System Programming *Concurrent computing *
картинка для привлечения внимания

Знание об управлении потоками, которое мы получили в прошлом топике, конечно, велико, но вопросов остаётся всё равно много. Например: «Как работает happens-before?», «Правда ли, что volatile — это сброс кешей?», «Зачем вообще было городить какую-то модель памяти? Нормально же всё было, что началось-то такое?»

Как и прошлая статья, эта построена по принципу «сначала кратко опишем, что должно происходить в теории, а потом отправимся в исходники и посмотрим, как это происходит там». Таким образом, первая часть во многом применима не только к Java, а потому и разработчики под другие платформы могут найти для себя что-то полезное.
Go Deeper
Total votes 86: ↑85 and ↓1 +84
Views 79K
Comments 45