JAVA → Java. Остановись задача из песочницы
Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.
JAVA → Что вы предпочтете для осуществления простейшего эксклюзивного доступа, исходя из производительности
Python → Конкурентность в асинхронном приложении на примере twisted из песочницы
Теоретически, проблема конкурентного доступа не характерна для асинхронных приложений. В отличие от приложений с параллельной архитектурой, в которых в каждый момент времени может выполняться несколько задач претендующих на какой то общий ресурс — в асинхронном приложении в один момент времени выполняется только одна активность.
Но на практике все выглядит немного по иному:
Но на практике все выглядит немного по иному:
JAVA → Новый синхронизатор Phaser
Phaser (Этапщик) — мощная и гибкая реализация паттерна синхронизации Барьер. Включен в JDK 7 в составе пакета java.util.concurrent.
Поскольку в документации, как говорится, без ста грамм не разберешься, опишу тут принцип действия, неочевидные моменты и приведу несколько примеров использования.
Поскольку в документации, как говорится, без ста грамм не разберешься, опишу тут принцип действия, неочевидные моменты и приведу несколько примеров использования.
JAVA → java.util.concurrent. Часть первая: Зачем и почему?
Часть первая, в которой множеством слов раскрывается смысл существования этого API
Эта статья, хоть и не является прямым переводом, основана на статье Брайана Гетца Concurrency in JDK 5.0
Эта статья, хоть и не является прямым переводом, основана на статье Брайана Гетца Concurrency in JDK 5.0
.NET → PLINQ: распределение данных между рабочими потоками
Пусть имеется некоторая последовательность элементов, которую мы хотим обработать при помощи PLINQ-запроса. При этом есть некоторое количество физических ядер CPU, готовых выполнять рабочие потоки. Как распределить элементы входной коллекции между потоками?
JAVA → Многопоточность: в какую сторону думать
Не так давно я по некоторому стечению обстоятельств принял участие в своеобразном соревновании, которое довольно быстро превратилось в исследование. Это исследование дало результаты, которые будут интересны читателям блогов Java и Алгоритмы в равной степени. По невозможности разместить сразу в двух местах, этот пост я решил разбить на две части. Как вам наверняка подсказывает Капитан, эта часть расскажет о результатах, касающихся Java.
Кстати, из исследовательской команды не только я зарегестрирован на Хабре: если хотите выразить благодарность, то не забывайте о markiz и icekeeper.
Разработка → Что такое транзакционная память и чем она полезна
По мере того, как многоядерные процессоры получают все большее и большее распространение, умение писать программы, использующие все доступные процессоры становится все более и более важным. Давайте рассмотрим то, почему существующие широко используемые средства написания программ для многоядерных процессоров не достаточно хорошее решение, что такое транзакционная память, и как она решает указанную проблему.
Переводы → What's all this fuss about Erlang?
by Joe Armstrong
Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.
Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.
Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.
Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.
Хорошие новости для Erlang-программистов:
На N-ядерном процессоре ваша программа будет работать в N раз быстрее.
Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.
Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.
Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.
Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.
Хорошие новости для Erlang-программистов:
На N-ядерном процессоре ваша программа будет работать в N раз быстрее.