Меня Arc-и всегда пугали именно этим.
===
? !:
Всем привет. Новичок и нуждаюсь в небольшом совете.
Есть приложение, реализовано на нативных потоках Rust (thread::spawn) с обменом сообщениями между потоками при помощи mpsc и данными между потоками, доступными через Arc::new(Mutex::new(данные)).
Все работает прекрасно, за исключением того, что периодически случаются deadlock'и (для доступа к данным использую Arc::clone(переменная, полученная выше из Arc::new(Mutex::new(данные))), который внутри потока .lock().unwrap(), использую данные и тут же выполняю drop() на MutexGuard, который получил из lock().unwrap() выше. Проблема в том, что все равно успевает произойти deadlock.
Покопавшись в теме, я так понял, что нужно вместо lock() использовать try_lock() и если он не прошел, то пытаться получить через try_lock() MutexGuard снова. Только как организовать это получение при помощи try_lock()? Пытался чудить что-то с while let и loop, но успехом это не закончилось
Vetro:
возможно не совсем в тему совет, но у parking_lot есть классная фича -
https://amanieu.github.io/parking_lot/parking_lot/deadlock/index.html
если есть возможность подтянуть эту библиотеку, вместо дефолтных мутексов (вместо которых, кстати говоря, хотят вмержить эту либу, или по крайней мере, точно хотели)
> Покопавшись в теме, я так понял, что нужно вместо lock() использовать try_lock()
нет, так не работает.
Berkus Decker:
надо проанализировать паттерн работы с локами и расставлять их так чтобы не было дедлоков.
===
via https://t.iss.one/rustlang_ru/311650
===
? !:
Всем привет. Новичок и нуждаюсь в небольшом совете.
Есть приложение, реализовано на нативных потоках Rust (thread::spawn) с обменом сообщениями между потоками при помощи mpsc и данными между потоками, доступными через Arc::new(Mutex::new(данные)).
Все работает прекрасно, за исключением того, что периодически случаются deadlock'и (для доступа к данным использую Arc::clone(переменная, полученная выше из Arc::new(Mutex::new(данные))), который внутри потока .lock().unwrap(), использую данные и тут же выполняю drop() на MutexGuard, который получил из lock().unwrap() выше. Проблема в том, что все равно успевает произойти deadlock.
Покопавшись в теме, я так понял, что нужно вместо lock() использовать try_lock() и если он не прошел, то пытаться получить через try_lock() MutexGuard снова. Только как организовать это получение при помощи try_lock()? Пытался чудить что-то с while let и loop, но успехом это не закончилось
Vetro:
возможно не совсем в тему совет, но у parking_lot есть классная фича -
https://amanieu.github.io/parking_lot/parking_lot/deadlock/index.html
если есть возможность подтянуть эту библиотеку, вместо дефолтных мутексов (вместо которых, кстати говоря, хотят вмержить эту либу, или по крайней мере, точно хотели)
> Покопавшись в теме, я так понял, что нужно вместо lock() использовать try_lock()
нет, так не работает.
Berkus Decker:
надо проанализировать паттерн работы с локами и расставлять их так чтобы не было дедлоков.
===
via https://t.iss.one/rustlang_ru/311650
amanieu.github.io
parking_lot::deadlock - Rust
API documentation for the Rust `deadlock` mod in crate `parking_lot`.
Forwarded from Alexander Chichigin
В очередной раз порекомендую прекрасную https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html 😊
Forwarded from 𝙽𝚒𝚌𝚔 𝙻𝚒𝚗𝚔𝚎𝚛
Началось всё с проблемы четырёх красок. Это довольно трудная задача, об которую сломали головы не одна сотня исследователей, она формулируется очень просто, впервые озвучена в 1852-м, но доказать её потребовалось довольно много десятков лет (не так, как для теоремы Ферма, но тоже хадкорно). Вот она:
Верно ли, что любую карту на плоскости или сфере можно раскрасить с помощью только 4х красок так, что если области имеют общую границу, то они разного цвета
И вот в 1976 году было предоставлено доказательство, которое выглядело так, что любая карта (а точнее граф) сводилась к одному из примерно 1936 случаев, а затем каждый из случаев был доказан с помощью компьютерной программы.
Это породило нешуточный срач, многие математики не приняли эту новаторскую идею, потому что
1. А вдруг алгоритм содержит ошибку, а вручную проверить все 1936 случаев руками этот алгоритм почти невозможно
2. А вдруг реализация алгоритма содержит ошибку?
3. А вдруг сам процессор содержит ошибку?
Финальную точку и поставило появление Coq, в отличие от других программ он содержал доказательство самого себя и кроме этого ещё и достаточно скрупулёзно исследован. Было сделано доказательство для проблемы 4х красок и теперь возможность для ошибки стала ничтожной, во всяком случае не существует техники доказательств, которая бы обеспечивала меньшую возможность для ошибок.
Верно ли, что любую карту на плоскости или сфере можно раскрасить с помощью только 4х красок так, что если области имеют общую границу, то они разного цвета
И вот в 1976 году было предоставлено доказательство, которое выглядело так, что любая карта (а точнее граф) сводилась к одному из примерно 1936 случаев, а затем каждый из случаев был доказан с помощью компьютерной программы.
Это породило нешуточный срач, многие математики не приняли эту новаторскую идею, потому что
1. А вдруг алгоритм содержит ошибку, а вручную проверить все 1936 случаев руками этот алгоритм почти невозможно
2. А вдруг реализация алгоритма содержит ошибку?
3. А вдруг сам процессор содержит ошибку?
Финальную точку и поставило появление Coq, в отличие от других программ он содержал доказательство самого себя и кроме этого ещё и достаточно скрупулёзно исследован. Было сделано доказательство для проблемы 4х красок и теперь возможность для ошибки стала ничтожной, во всяком случае не существует техники доказательств, которая бы обеспечивала меньшую возможность для ошибок.
Дыры в системах типов Java и Scala. Когда практики берутся за статическую типизацию без хорошо проработанной теории, выходит такое (Scala, по-видимому, вынуждена была включить джавовские типы для интеропа).
Forwarded from Doctor Foland
А можно пример такой парадоксальной системы типов?