Oberon space
General Category => Общий раздел => Тема начата: Губанов Сергей Юрьевич от Февраль 09, 2012, 04:27:29 pm
-
Интересно чем это нам "грозит"?
Процессоры Haswell станут большим скачком в развитии CPU (http://www.overclockers.ru/hardnews/45756/Processory_Haswell_stanut_bolshim_skachkom_v_razvitii_CPU.html)
В своём блоге компания Intel сообщила о том, что в процессорах с архитектурой Haswell будет реализован механизм транзакционной памяти, предполагающий одновременное выполнение сложных многопоточных операций, но при этом изолированно друг от друга, что исключает "крах" всей программы из-за ошибки в одном потоке.
В архитектуре Haswell данный механизм назван Transactional Synchronization Extensions (TSX), который, в свою очередь, разделяется на две основные части: Hardware Lock Elision (HLE), транслирующую "обычные" программы в транзакционные с сохранением работоспособности, и Restricted Transactional Memory (RTM), что является, непосредственно, транзакционной памятью.
В нынешних компьютерных системах распределением ресурсов вычислительных ядер занимается операционная система, но разработчики намереваются переложить эти обязанности на аппаратную часть. Процессор сам будет определять, когда, как и с каким потоком данных ему работать, также аппаратная часть будет заниматься распределением памяти, решая, какие данные могут разделять общую память, а для каких требуется выделенное пространство.
Подобные механизмы реализованы в некоторых СУБД, но Intel намеревается внедрить поддержку транзакционной памяти на аппаратном уровне повсеместно. Впрочем, разработчики говорят о сопутствующих технических сложностях, и процессоры Haswell, скорее всего, будут лишь экспериментом в освоении новых технологий.
-
Интересно чем это нам "грозит"?
Придется больше писать на хаскеле? :)
-
По моему, щажу гцц поддерживает транзакционную память. Софтварно конечно. Для сей. Вообще, такой подход (особенно с поддержкой на аппаратном уровне) сильно облегчит программирование многопоточных приложений. И, главное, это будет эффективно. Наверно даже эффективней того что есть сейчас в хаскелле. (в .net msr пробовали тоже реализовать tm, но из за особенностей .net получилось очень не эффективно)
-
Интересно чем это нам "грозит"?
Статья провокационная... она вброшена для затравки. Думаю, что таких пустых статей появится много в ближайшее время, их задача состоит в том, чтобы напустить тумана... вызвать обсуждения, и потом Intel явит миру очередное решение.
Давайте попробуем поразмышлять. Первое, что наводит на размышления.. меня... это ссылка на СУБД. Якобы, некоторые СУБД поддерживают транзакционность? Хотелось бы отметить, что не может быть СУБД без поддержки требований ACID. Системы без транзакционности не имеют права называться СУБД, это давно пережёвано базовиками.
Второе. Требования ACID подразумевают (Durability Долговечность), как это будет соблюдено в оперативной памяти, например, при отключении электроэнергии?.. А без долговечности понятие транзакции повисает в воздухе.
Но это только то, что на поверхности. Дело в том, что требования ACID и, собственно, транзакционность можно реализовать двумя способами. Третье. Предположим, что с одним набором данных работают несколько заинтересованных транзакций. Если все заинтересованные транзакции "читающие", то проблем не возникает... Пусть им... Но если появляется хотя бы одна "пишущая", то... что должны читать остальные? То, что было до того, как произошли изменения, или то, что произошло после изменений?.. СУБД вводят понятие изолированности (Isolation Изолированность), которое определяет то, что меняет одна транзакция, не должно влиять на другие параллельные транзакции. Исключить влияние можно двумя принципиально разными способами: блокировками или версиями. Блокировочный механизм подразумевает, что все параллельные транзакции, кроме авторской, обращающиеся к изменённым данным, приостанавливаются до завершения (commit|rollback - фиксация|откат) авторской транзакции. В результате порождаются зависимости по данным, и если "пишущих" транзакций более одной, то возможны dead lock ("мёртвые захваты"). Простой пример, транзакция А изменила данные альфа и ждёт, когда транзакция Б освободит изменённые данные бета, А транзакция Б ждёт, когда ей освободят данные альфа. Так ждать они могут до второго пришествия включения компьютера... То есть, нужен интеллектуальный механизм арбитража, способный распутывать большие узлы взаимно ожидающих транзакций (при этом хотя бы одна транзакция будет откачена (rollback)). Что означает rollback для потока?.. К какому состоянию его окатывать?.. Какие локальные переменные при этом нужно восстановить?.. Где будут храниться их прежние значения (и какие версии?)?..
Версионный механизм подразумевает, что каждой пишущей транзакции "подсовыватся" свой вариант памяти. Простой пример. Есть набор данных расположенный в общедоступной памяти. Этот набор данных (реально набор страниц памяти) защищён от ВСЕХ транзакций флагом read only. Если какая-то транзакция пытается изменить данные, возникает исключение, и этой транзакции в её адресное пространство "подсовывается" новая страница с разрешением записи, на которую скопированы данные из общего набора. Естественно, транзакция ничего не знает о подмене и успешно пишет на новую страницу (разрешено!). Проблемы могут возникнуть при проекции изменённых разными транзакциями страниц на общий набор данных. Как на уровне процессора разрешить эту проблему не более понятно, чем то, как распутать "dead locks".
И напоследок догадки... Есть подозрение, что помимо двух таблиц памяти: GDT и LDT (global and local descripion table), Intel хочет ввести новую таблицу PDT (private description table) (название условное). Эта таблица будет отвечать за распределение памяти потоку внутри процесса. На работу с этой таблицей будут наложены определённые правила/ограничения... и на этом всё завершится. Все рассуждения о транзакциях - это просто ПИАР. Это выглядит вполне логичным если учесть два обстоятельства:- адресное пространство сейчас излишне велико для подавляющего большинства приложений;
- с переходам к множеству (тысячи, если говорить об APU) процессоров возникают проблемы с когерентностью областей памяти, и эти проблемы отчасти можно решить на аппаратном уровне
Так чем же нам всё это грозит?.. Переходом к параллельным вычислениям... ничем больше, ничем меньше.
-
Конкретно про gcc вот: http://gcc.gnu.org/wiki/TransactionalMemory