Почему является незапертый параллелизм таким грандиозным предприятием (в Clojure)?
Вот решение Kotlin:
if ( this.getSupportFragmentManager().getBackStackEntryCount()>0 ) {
var fgmt = this.getSupportFragmentManager().fragments[this.getSupportFragmentManager().getBackStackEntryCount()-1]
if( fgmt is FgmtClassName ) {
(fgmt as FgmtClassName).doSth()
}
}
Упрощенный путь:
with ( this.getSupportFragmentManager() ) {
if ( getBackStackEntryCount()>0 ) {
var fgmt = fragments[getBackStackEntryCount()-1]
if ( fgmt is FgmtClassName ) {
(fgmt as FgmtClassName).doSth()
}
}
}
6 ответов
Я не могу говорить конкретно о Clojure, но ... это означает, что вам не нужно ждать, пока кто-то что-то сделает, прежде чем вы сможете приступить к работе. Что здорово.
Обычно это достигается с помощью неизменяемых типов. Если ничего нельзя изменить, вам действительно не нужно ждать, пока кто-то другой закончит с этим, прежде чем вы сможете получить к нему доступ.
Преимуществом безблокирующего параллелизма является отсутствие сложности программы. В императивных языках параллельное программирование полагается на блокировки, и как только программа становится даже умеренно сложной, вкрадываются трудно исправляемые тупиковые ошибки.
Тупики. Или, точнее говоря, их отсутствие.
Одна из самых больших проблем в большинстве языков заключается в том, что вы попадаете в тупики, а именно:
- Ад на землю для отладки.
- Трудно быть уверенным, что вы получили rid.
Теперь, когда нет блокировок, очевидно, что вы не попадете в тупик.
Параллелизм без блокировки также дает приятное преимущество, заключающееся в том, что читателям никогда не приходится ждать других читателей. Это особенно полезно, когда многие потоки будут читать данные из одного источника. Вам по-прежнему необходимо определить зависимости данных в вашей программе и явно определить части транзакции, которые можно безопасно коммутировать.
STM избавляет вас от взаимоблокировок и почти всех случаев livelock, хотя он не спасает вас от сбоев параллелизма, вы все равно можете создавать случаи, когда транзакция завершится ошибкой из-за нехватки ресурсов для ведения своей истории, но важная часть состоит в том, что сбои параллелизма будут явными, и вы сможете восстановить их
Пока вы пишете строго последовательные программы (выполните A, затем B, затем C; готово!), У вас нет проблем с параллелизмом, а механизмы параллелизма языка остаются неуместными.
Когда вы переходите от программ "упражнений по программированию" к реальным вещам, довольно скоро вы сталкиваетесь с проблемами, решение которых - многопоточность (или любой другой вариант параллелизма, который у вас есть).
Пример: Программы с графическим интерфейсом пользователя. Допустим, вы пишете редактор с проверкой орфографии. Вы хотите, чтобы программа проверки орфографии выполняла свою работу в фоновом режиме, но при этом вы хотите, чтобы графический интерфейс плавно принимал вводимые пользователем данные. Таким образом, вы выполняете эти два действия как отдельные потоки.
Случай: я недавно написал программу (для работы), которая собирает статистику из двух файлов журнала и записывает ее в базу данных. Обработка каждого файла занимает около 3 минут. Я переместил эти процессы в два потока, которые выполняются бок о бок, сократив общее время обработки с 6 минут до немногим более 3.
Пример: программное обеспечение для научного / инженерного моделирования. Существует множество проблем, которые решаются путем вычисления некоторого эффекта (например, теплового потока) в каждой точке трехмерной сетки, представляющей вашего испытуемого (звездное ядро, ядерный взрыв, географическое рассредоточение популяции насекомых ...). По сути, одни и те же вычисления выполняются в каждой точке и во многих точках, поэтому имеет смысл выполнять их параллельно.
Во всех этих и многих других случаях, когда два вычислительных процесса обращаются к одной и той же памяти (= переменные, если хотите) примерно в одно и то же время они могут мешать друг другу и мешать работе друг друга.
Such "lockless concurrency" isn't really a feature of a language; rather, it's a feature of a platform or runtime environment, and woe be the language that won't get out of the way to give you access to these facilities.
Thinking about the trades between lock-based and lock-free concurrency is analogous to the metacircular evaluator problem: one can implement locks in terms of atomic operations (e.g. compare-and-swap, or CAS), and one can implement atomic operations in terms of locks. Which should be at the bottom?