Здравствуйте, vdimas, Вы писали:
V>А ты вообще хорошо себя чувствуешь — почитал какое-то руководство для пользователей к какой-то СУБД и с этими "знаниями" наперевес побежал спорить.


V>Нет таких отличий.
V>В базе есть механизм семафора, у того счётчик.
V>Остальные примитивы сигнализации производные.
Очень интересно.

S>>RO и RW блокировки в вашей терминологии.
V>Отношение RO и RW блокировок примерно равны отношению блокировок строк и страницы целиком, где эти строки располагаются.
V>(разве что у каждой строки есть своя блокировка, зависит от уровня изоляции).
V>Заявки, блокирующие строки, эквиваленты читателям, а блокирующие всю страницу — писателям.
Очень интересно. А read-заявки на строки эквивалентны write-заявкам на строки? У нас получилось четыре вида блокировок, кто из них кому эквивалентен?

V>Изначально значение семафора ресурса "достаточно большое" (не имеет смысла ставить выше уровня конкурентности многопроцессорной системы).

V>При появлении писателя семафору ресурса присвается значение счётчика "минус кол-во читателей плюс один".
Ага, то есть вы имеете в виду не "настоящий" семафор, а что-то самописаное, так?
Тогда было бы неплохо привести код.
V>Когда последний читатель освободит ресурс, писатель сможет его захватить.
Хм. Непонятно вот что: как мы делаем замену значения семафора при "появлении писателя"?
Как будет выглядеть освобождение семафора писателем? Классический release делает простой инкремент — то есть захватить блокировку сможет не более 1 читателя/писателя.
Если мы сделаем опять инкремент на "большое значение", а в очереди несколько писателей, то может произойти совместный захват.

V>Одно но — на многопроцессорной машине в режиме вытесняющей многозадачности наших "очередей" нет, есть очереди уровня ОС, поэтому возможно голодание писателей, т.к. даже при ограничении доступа к ресурсу счётчиком 1, его могут захватить конкурентные потоки-читатели.
V>Решается это либо системой управляемых приложением очередей, либо доп.механизмом на семафоре со счётчиком 1 — на т.н. турникете.
Отлично. То есть у нас уже как минимум самописанный семафор (поверх какого-то механизма синхронизации ОС) +турникет. Ну, либо очередь, управляемая приложением, что вообще множит всю идею единственного семафора на ноль.
Давайте добавим в смесь update блокировки. Как вы реализуете их на одном семафоре, вместе с shared и exclusive?

V>Т.е., система прикладных очередей предпочтительней в случае сложных иерархических блокировок, реализцется, например, через асинхронщину или "зеленые потоки", когда мы сами управляем нагрузкой, бо лишние примитивы сигнализации всегда дороги, да еще потенциально вносят помехи в системах с вытесняющей многозадачностью — например, поток читателя должен пройти через турникет, т.е. дёрнуть примитив сигнализации дважды, но поток может быть вытеснен после первой фазы прохода через турникет и тогда этот поток затормозит всех — и читателей и писателей.
Вижу, вы начинаете понимать сложности реализации разделения ресурсов в СУБД.

V>В общем, при организации сложных иерархий доступа к ресурсам рулит кооперативная многозадачность.
V>В этом смысле планировщики ОС тупые. ))
V>Не потому что алгоритмы планировщика тупые, а потому что эти алгоритмы не обладают информацией о происходящем на прикладном уровне.
Ок, давайте рассмотрим организацию сложных иерархий доступа к ресурсам.

V>В системе с явными очередями читатели поступают из многих очередей (столько очередей, какова конкурентность системы), а писатели поступают из одной.
V>При появлении первого писателя все вновь поступающие читатели ставятся в очередь писателей (либо эти очереди просто "перекрываются").
V>При появлении из той очереди первого читателя они опять раскидываются по очередям читателей до появления первого писателя (либо очереди читателей опять открываются) и т.д.по кругу.
V>Простой и элегантный алгоритм, рекомендую.
Непонятно описываете.
V>Этим же алгоритмом точно так же элегантно обслужишь отношение блокировок уровня строки и страницы.
Это как это так? Я тупой, не понимаю, как устроен примитивы "захватить shared row lock", "отпустить shared row lock", "захватить exclusive row lock", "отпустить exclusive row lock" в такой системе.
Что такое "очереди перекрываются"? Как добавить в этот простой и элегантный алгоритм update lock?

И тем более я не понимаю, как одним и тем же алгоритмом мы будем обрабатывать ещё и shared page lock и exclusive page lock. Сколько у нас будет очередей?

V>И да, небольшой хинт — при попытках расписывать происходящее на семафорах не имеет смысла думать семафорами уровня ОС, где очереди к семафорам "даны сверху", а сами ОС реализуют выталкивающую многозадачность.
Да, семафорами уровня ОС это просто невозможно сделать. Ну, например, просто потому, что нет метода "заменить текущее значение семафора на -x"
V>Представь, что у тебя есть просто модель счётчика, управлять которым ты можешь атомарно.
V>Если не охота возиться с зелеными потоками, то в моделирующей программе это можно сделать, например, через цикл CAS:
V>

V>while(!CAS(&sema_counter, new_value, old_Value)) {
V>  asm ("pause");
V>  old_value = sema_counter;
V>  new_Value = calc_new_value(oldValue);
V>}
V>

Ну, вот пока что в голове полная схема не выстраивается. Ни с семафором, ни с очередями.