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

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

Будет ли это общее усыновление? Высокоскоростной? Улучшенная надежность? На сколько?

Для тех, кто их не видел, транзакции памяти действуют как транзакции базы данных: операции выполняются (по-видимому) параллельно, и если существует конфликт между двумя транзакциями (например, они обе записывают одно и то же значение), то одна или обе транзакции будет откат и перезапуск.

Транзакционная память имеет несколько преимуществ:

  1. Надежность Полная свобода от блокировок (например, блокировка неправильного порядка).
  2. Производительность Большая скорость при низкой конкуренции за блокировки.
  3. Программируемость Детальное управление параллелизмом без множества объектов синхронизации для управления.

Однако даже при условии правильной, полной и быстрой реализации TM есть известные недостатки этого примитива по сравнению с блокировками.

  1. Поскольку транзакции могут выполняться несколько раз, прогнозировать производительность сложнее, кроме как с помощью эмпирического эксперимента.

    Можем ли мы воспроизвести ошибки производительности?

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

    Можем ли мы адекватно понять локальные эффекты нашего кода?

  3. Чтобы поддерживать безотзывное поведение (например, отправку команды "пожарные ракеты") в транзакции, для которой выполняется откат, время выполнения становится более сложным.

    Можем ли мы адекватно понять глобальные эффекты нашего кода?

И, наконец, поскольку программные реализации, вероятно, будут использоваться первыми (уже есть реализации на C, C++, Haskell, Clojure и Scala и многие другие), на самом деле существует проблема с производительностью. При умеренной конкуренции программные транзакции снижают производительность.

Каков ваш бюджет производительности? В какой момент выгоды перевешивают потенциальные затраты?

Источник

3 ответа

Я провел некоторые эксперименты с TBoost STM, и он, кажется, пригоден для использования, хотя мне пока не удобно использовать его в производственном продукте. Однако необходимо изменить мышление, поэтому я сомневаюсь, что оно получит популярность, если не продемонстрирует убедительных преимуществ в реальных приложениях.

Я продолжаю слышать, что будущее за массивно параллельными вычислениями, так как процессоры начинают удваиваться в ядрах, как это было раньше, удваивая частоту. Пока что 4- и 8-ядерные десктопы не очень полезны для общих рабочих нагрузок. Я думаю, что у нас есть небольшая проблема: освоение параллельных машин требует программного обеспечения, способного использовать все преимущества, в то время как основная разработка высокопараллельного программного обеспечения ожидает повсеместного использования высокопараллельного оборудования.

Я думаю, что, пожалуй, нужен программный проект с открытым исходным кодом для принятия модели STM для чего-то вроде веб-сервера. Такой успешный проект был бы отличной моделью и мог бы помочь заинтересовать всю индустрию программного обеспечения, доказав, что STM готов к реальному миру.

Источник

Несколько вещей:

1) Система программной транзакционной памяти (STM) должна быть надежной, надежной и протестированной, чтобы она действительно работала.

2) Снижение производительности безусловной транзакции STM должно быть сопоставимо с той же самой процедурой с неоспоримой блокировкой.

3) Система STM должна работать значительно лучше, когда несколько транзакций ожидают против использования блокировки оспариваемых ресурсов.

Источник

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

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

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

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

Правильность: пользователь должен быть уверен, что система, которую он / она использует, является правильной как в ее основе, так и в ее реализации. Большинство современных систем STM не находятся на стадии разработки продукта, поэтому люди могут на мгновение пострадать от нестабильных версий.

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

Источник
Другие вопросы по тегам