Сообщение Re[12]: секунда WTF (lock) от 29.01.2017 14:00
Изменено 29.01.2017 14:01 Sinix
Re[12]: секунда WTF (lock)
Здравствуйте, samius, Вы писали:
S>>Ну тут всё от доверия к коду зависит. Для произвольного кода только проверки на уровень иерархии лока недостаточно, как по мне.
S>Хорошо, а чего будет достаточно?
Ну как минимум — отслеживание всех блокирующих вызовов (их не так уж и много). Иначе будут неловящиеся дедлоки, пример уже подкидывал. В идеале — ещё и трассировку async-callback-ов добавить, через asynvc local. Но это уже по желанию.
S>Текущий проект, над которым работаю — сервис, обслуживающий коллбэки из драйвера файловой системы. Типа смарткэша для облачного файлового хранилища (корпоративного, не личного).
S>Блокировками (в том числе) защищена единая модель дерева файлов в памяти.
А. Мы такое когда-то делали на очередях и cqrs-style (хотя тогда cqrs ещё в моде вроде не был... что-то подобное короч) уведомлениях об изменении данных. Но у нас не было требования консистентности, т.е. модель в памяти могла отражать содержимое файлов с некоторой задержкой. Ну, и данные делились так, чтобы отдельные части можно было безопасно обновлять параллельно, каждая часть обрабатывалась в один поток. В общем, 9/10 всех костылей было убрано ещё в момент проектирования и работать было сплошным удовольствием.
Если требование консистентности есть — то да, жизнь становится заметно интереснее
S>>Ну тут всё от доверия к коду зависит. Для произвольного кода только проверки на уровень иерархии лока недостаточно, как по мне.
S>Хорошо, а чего будет достаточно?
Ну как минимум — отслеживание всех блокирующих вызовов (их не так уж и много). Иначе будут неловящиеся дедлоки, пример уже подкидывал. В идеале — ещё и трассировку async-callback-ов добавить, через asynvc local. Но это уже по желанию.
S>Текущий проект, над которым работаю — сервис, обслуживающий коллбэки из драйвера файловой системы. Типа смарткэша для облачного файлового хранилища (корпоративного, не личного).
S>Блокировками (в том числе) защищена единая модель дерева файлов в памяти.
А. Мы такое когда-то делали на очередях и cqrs-style (хотя тогда cqrs ещё в моде вроде не был... что-то подобное короч) уведомлениях об изменении данных. Но у нас не было требования консистентности, т.е. модель в памяти могла отражать содержимое файлов с некоторой задержкой. Ну, и данные делились так, чтобы отдельные части можно было безопасно обновлять параллельно, каждая часть обрабатывалась в один поток. В общем, 9/10 всех костылей было убрано ещё в момент проектирования и работать было сплошным удовольствием.
Если требование консистентности есть — то да, жизнь становится заметно интереснее
Re[12]: секунда WTF (lock)
Здравствуйте, samius, Вы писали:
S>>Ну тут всё от доверия к коду зависит. Для произвольного кода только проверки на уровень иерархии лока недостаточно, как по мне.
S>Хорошо, а чего будет достаточно?
Ну как минимум — отслеживание всех блокирующих вызовов (их не так уж и много). Иначе будут неловящиеся дедлоки, пример уже подкидывал. В идеале — ещё и трассировку async-callback-ов добавить, через async local. Но это уже по желанию.
S>Текущий проект, над которым работаю — сервис, обслуживающий коллбэки из драйвера файловой системы. Типа смарткэша для облачного файлового хранилища (корпоративного, не личного).
S>Блокировками (в том числе) защищена единая модель дерева файлов в памяти.
А. Мы такое когда-то делали на очередях и cqrs-style (хотя тогда cqrs ещё в моде вроде не был... что-то подобное короч) уведомлениях об изменении данных. Но у нас не было требования консистентности, т.е. модель в памяти могла отражать содержимое файлов с некоторой задержкой. Ну, и данные делились так, чтобы отдельные части можно было безопасно обновлять параллельно, каждая часть обрабатывалась в один поток. В общем, 9/10 всех костылей было убрано ещё в момент проектирования и работать было сплошным удовольствием.
Если требование консистентности есть — то да, жизнь становится заметно интереснее
S>>Ну тут всё от доверия к коду зависит. Для произвольного кода только проверки на уровень иерархии лока недостаточно, как по мне.
S>Хорошо, а чего будет достаточно?
Ну как минимум — отслеживание всех блокирующих вызовов (их не так уж и много). Иначе будут неловящиеся дедлоки, пример уже подкидывал. В идеале — ещё и трассировку async-callback-ов добавить, через async local. Но это уже по желанию.
S>Текущий проект, над которым работаю — сервис, обслуживающий коллбэки из драйвера файловой системы. Типа смарткэша для облачного файлового хранилища (корпоративного, не личного).
S>Блокировками (в том числе) защищена единая модель дерева файлов в памяти.
А. Мы такое когда-то делали на очередях и cqrs-style (хотя тогда cqrs ещё в моде вроде не был... что-то подобное короч) уведомлениях об изменении данных. Но у нас не было требования консистентности, т.е. модель в памяти могла отражать содержимое файлов с некоторой задержкой. Ну, и данные делились так, чтобы отдельные части можно было безопасно обновлять параллельно, каждая часть обрабатывалась в один поток. В общем, 9/10 всех костылей было убрано ещё в момент проектирования и работать было сплошным удовольствием.
Если требование консистентности есть — то да, жизнь становится заметно интереснее