Здравствуйте, samius, Вы писали:

S>>Вся разница — надёжней и больше сценариев покрывается.
S>За счет чего более полное-то? Просто убирается хак и только лишь.

За счёт того, что покрываются RW lock, Thread.Join, Semaphore.WaitOne() и прочие примитивы синхронизации.


S>>В смысле не принудительно? Подключил библиотеку — получи тип System.Threading.Monitor в подарок. Или мы уже какое-то другое решение обсуждаем?
S>Подключил — получи Monitor — абсолютно не вариант.
Ну я про это же говорю. Отдельной библиотекой — почему бы и нет?


S>Не, тут либо я что-то не понял, либо теряется часть сценариев. Не нужно требовать что бы перед локом таким-то обязательно был взят такой-то. Это более сильное требование, чем необходимо. Если можно взять b после a, то можно взять b и без a, но если взял b — не бери a. Это делает родителей необязательными.
Не, ссылка на родителя — только чтобы автоматом получать уровень блокировки, не прописывая циферки ручками. Остальное как у тебя.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>За счет чего более полное-то? Просто убирается хак и только лишь.

S>За счёт того, что покрываются RW lock, Thread.Join, Semaphore.WaitOne() и прочие примитивы синхронизации.
Теперь понял.


S>>>В смысле не принудительно? Подключил библиотеку — получи тип System.Threading.Monitor в подарок. Или мы уже какое-то другое решение обсуждаем?
S>>Подключил — получи Monitor — абсолютно не вариант.
S>Ну я про это же говорю. Отдельной библиотекой — почему бы и нет?
смысл в отдельной пропадает, если не хакать lock. Да в общем, если охват будет более полный, то можно и отдельной.


S>>Не, тут либо я что-то не понял, либо теряется часть сценариев. Не нужно требовать что бы перед локом таким-то обязательно был взят такой-то. Это более сильное требование, чем необходимо. Если можно взять b после a, то можно взять b и без a, но если взял b — не бери a. Это делает родителей необязательными.
S>Не, ссылка на родителя — только чтобы автоматом получать уровень блокировки, не прописывая циферки ручками. Остальное как у тебя.
Т.е. ссылка на родителя — разметка для инструмента, который уровни вычислит по меткам и подставит сам? Идея нравится, но не до конца.

Допустим, есть некая утилита, защищенная отдельным локом (сегодня). И этот отдельный лок не нуждается ни в каком контроле, т.к. мы уверены что из кода этой утилиты любой другой код не вызывается, она закончена. Завтра чел в нее добавляет виртуальный метод, объявляет наследника, добавляет фабрику. Послезавтра один из наследников начинает вызывать код бизнес-уровня. Именно поэтому контроль лока для этой утилиты нужен сегодня. Но какого родителя ему указать, какого из, если сегодня он может вызываться из 10и разных мест кода? А сейчас я всобачиваю туда константу LockLevels.Utilities = int.MaxValue;
Можно и не указывать родителя, тогда назначать уровень исходя из предположения что из под этого лока уже никого не вызовут.
Вообще лучше видеть карту уровней на одном экране, что бы можно было над ней курить, не носясь по исходникам. ИМХО.

Здравствуйте, samius, Вы писали:

S>Т.е. ссылка на родителя — разметка для инструмента, который уровни вычислит по меткам и подставит сам? Идея нравится, но не до конца.
Угу.

S>А сейчас я всобачиваю туда константу LockLevels.Utilities = int.MaxValue;
Ну так можно это дело флагом оформить или оставить возможность заполнять вручную. Или как ты написал —

назначать уровень исходя из предположения что из под этого лока уже никого не вызовут.

S>Вообще лучше видеть карту уровней на одном экране, что бы можно было над ней курить, не носясь по исходникам. ИМХО.
Не проблема абсолютно. В отладочных сборках добавляем дочерние lockobj в список, который хранится в корневом — профит.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>А сейчас я всобачиваю туда константу LockLevels.Utilities = int.MaxValue;
S>Ну так можно это дело флагом оформить или оставить возможность заполнять вручную. Или как ты написал —
S>

S>назначать уровень исходя из предположения что из под этого лока уже никого не вызовут.

Да, пусть так.

S>>Вообще лучше видеть карту уровней на одном экране, что бы можно было над ней курить, не носясь по исходникам. ИМХО.
S>Не проблема абсолютно. В отладочных сборках добавляем дочерние lockobj в список, который хранится в корневом — профит.
Угу, должно получиться здорово. В лучшем случае за это не будут бить (ногами (больно)). На большее не рассчитываю. То есть, обещать что впишусь в такой проект не стану. Но буду искренне рад, если это кому-то поможет (в любой форме).