История изменений
Исправление byko3y, (текущая версия) :
ну так, хотя бы самые легкие, «лоховские» ошибки нашел? Или философия такая: «если нельзя верифицировать параллельную логику - то и на примитивные ошибки наплевать»?
Мне кажется, что ты не представляешь, что такое множественная read-write блокировка с честностью. Все, кто до меня подумывал о реализации подобной штуки, просто соснули. Как правило, RW-блокировки пишутся для короткого доступа, желательно к одному ресурсу, и «билеты» они получают для одной-единственной блокировки. У меня же билеты глобальны, одна блокировка может быть отменена по конфликту в другой блокировке по глобальным билетам, и при этом желательно, чтобы после конфликта низкоприоритетная задача ждала окончания работы высокоприоритетной — последнее условие у меня не всегда выполняется, поскольку есть адовые варианты конфликтов, при которых не ясно, кто, кого, и когда вообще должен ждать. Потому что, напоминаю, пользоваться данными под одной блокировкой может большое число процессов, если они, например, только читают данные. Но еще может оказаться, что читатель решит стать писателем — и тогда ему нужно будет искать, кого ждать, а кого убивать. При этом другие задачи так же могут кого-то ждать и кого-то убивать, как по этой, так и другой блокировке.
Так вот, я добился 100% корректного выполнения, без дедлоков и без одновременного доступа к ресурсу. По крайней мере, на достаточно скромных наборах данных и 2-3 блокировках одновременно взятых.
Исправление byko3y, :
ну так, хотя бы самые легкие, «лоховские» ошибки нашел? Или философия такая: «если нельзя верифицировать параллельную логику - то и на примитивные ошибки наплевать»?
Мне кажется, что ты не представляешь, что такое множественная read-write блокировка с честностью. Все, кто до меня подумывал о реализации подобной штуки, просто соснули. Как правило, RW-блокировки пишутся для короткого доступа, желательно к одному ресурсу, и «билеты» они получают для одной-единственной блокировки. У меня же билеты глобальны, одна блокировка может быть отменена по конфликту в другой блокировке по глобальным билетам, и при этом желательно, чтобы после конфликта низкоприоритетная задача ждала окончания работы высокоприоритетной — последнее условие у меня не всегда выполняется, поскольку есть адовые варианты конфликтов, при которых не ясно, кто, кого, и когда вообще должен ждать. Потому что, напоминаю, пользоваться данными под одной блокировкой может большое число процессов, если они, например, только читают данные. Но еще может оказаться, что читатель решит стать писателем — и тогда ему нужно будет искать, кого ждать, а кого убивать. При этом другие задачи так же могут кого-то ждать и кого-то убивать, как по этой, так и другой блокировке.
Так вот, я добился 100% когрректного выполнения, без дедлоков и без одновременного доступа к ресурсу. По крайней мере, на достаточно скромных наборах данных и 2-3 блокировках одновременно взятых.
Исходная версия byko3y, :
ну так, хотя бы самые легкие, «лоховские» ошибки нашел? Или философия такая: «если нельзя верифицировать параллельную логику - то и на примитивные ошибки наплевать»?
Мне кажется, что ты не представляешь, что такое множественная read-write блокировка с честностью. Все, кто до меня подумывал о реализации подобной штуки, просто соснули. Как правило, RW-блокировки пишутся для короткого доступа, желательно к одному ресурсу, и «билеты» они получают для одной-единственной блокировки. У меня же билеты глобальны, одна блокировка может быть отменена по конфликту в другой блокировке по глобальным билетам, и при этом желательно, чтобы после конфликта низкоприоритетная задача ждала окончания работы высокоприоритетной — последнее условие у меня не всегда выполняется, поскольку есть адовые варианты конфликтов, при которых не ясно, кто, кого, и когда вообще должен ждать. Потому что, напоминаю, пользоваться данными под одной блокировкой может большое число процессов, если они, например, только читают данные. Но еще может оказаться, что читатель решит стать писателем — и тогда ему нужно будет искать, кого ждать, а кого убивать. При этом другие задачи так же могут кого-то ждать и кого-то убивать.
Так вот, я добился 100% когрректного выполнения, без дедлоков и без одновременного доступа к ресурсу. По крайней мере, на достаточно скромных наборах данных и 2-3 блокировках одновременно взятых.