S> Плохо у меня с английским.
Омг. http://msdn.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx
Имхо, у вас не с английским плохо, а с чем-то более другим.

S>Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
S>Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
S>то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.

S>Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.
Решает. Параллельное программирование — сложная материя. Не торопитесь, распишите по шагам, кто что захватывает, сверяясь с таблицей блокировок. Судя по всему, вы вообще не понимаете сценарий применения U-блокировок.

Дизайн, выбранный в MS SQL, может встрять только в одном случае — когда идет интенсивный перезахват S-блокировок на ресурс, которго ждёт транзакция с конверсией U->X. В жизни это бывает относительно редко; как правило, рано или поздно читатели всё же уходят.

S>Курить LSP до просветления.

ты не стрелки переводи, а давай пруф, что LSP имеет хоть какое-то отношение к наследованию реализаций.

В определении LSP явно сказано, что LSP про subtyping, а не про наследование.

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy

http://en.wikipedia.org/wiki/Liskov_substitution_principle

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


S>> Плохо у меня с английским.
S>Омг. http://msdn.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx
S>Имхо, у вас не с английским плохо, а с чем-то более другим.

S>>Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
S>>Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
S>>то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.

S>>Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.

Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.

S>Решает. Параллельное программирование — сложная материя. Не торопитесь, распишите по шагам, кто что захватывает, сверяясь с таблицей блокировок. Судя по всему, вы вообще не понимаете сценарий применения U-блокировок.

S>Дизайн, выбранный в MS SQL, может встрять только в одном случае — когда идет интенсивный перезахват S-блокировок на ресурс, которго ждёт транзакция с конверсией U->X. В жизни это бывает относительно редко; как правило, рано или поздно читатели всё же уходят.



Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?

S>Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
S>То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.
Вы опять ставите телегу впереди лошади. Надо делать не то, что "можно", а то, что необходимо.


S>Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?
Дальше я вас отправлю читать какой-нибудь учебник, например того же Бернстайна. И попрошу постараться воздержаться от написания бреда. Блокировка ничего не читает и не пишет. Читает и пишет процесс в рамках некой транзакции.
А блокировки выдаются и снимаются, они связывают процесс с ресурсом.
Вот в вашем сумбурном примере сколько участвует процессов? Как устроен код этих процессов? Почему вы задаёте вопрос про U-блокировки, но в примере нет ни одной U-блокировки?

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


S>>Добавлю, что можно наложить ограничение на чтение U блокировок, только тем транзакциям у которых уже есть совместные блокировки. А это может быть когда читающая транзакция была начата раньше окончания U блокировки.
S>>То есть всем транзакциям начавшимся позже окончания U блокировки отказывать в доступе.
S>Вы опять ставите телегу впереди лошади. Надо делать не то, что "можно", а то, что необходимо.


S>>Часто бывает интенсивное чтение например остатков и запись. Например Х блокировка блокирует записи 1,2,3,4 а S блокирует 4,3,2,1. Например S прочитала 4,3 а Х 1,2 что будет дальше?
S>Дальше я вас отправлю читать какой-нибудь учебник, например того же Бернстайна. И попрошу постараться воздержаться от написания бреда. Блокировка ничего не читает и не пишет. Читает и пишет процесс в рамках некой транзакции.
S>А блокировки выдаются и снимаются, они связывают процесс с ресурсом.
S>Вот в вашем сумбурном примере сколько участвует процессов? Как устроен код этих процессов? Почему вы задаёте вопрос про U-блокировки, но в примере нет ни одной U-блокировки?

Процесс или поток? U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
читать блокируемые записи.
Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.

Ого кстати а там есть UpgradeToWriterLock

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


S>Процесс или поток?
В СУБД используется термин "процесс".

S>U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
S> читать блокируемые записи.
Не надо мне рассказывать, что такое блокировки. Поверьте мне, ничего нового вы не расскажете.
Вопрос в чём?

S>Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
S>AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.
Ну, и в чём вопрос?

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

S> Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.

Если общий работает плохо, то на кой он нужен вообще? Лучше уж тогда всё прямоугольниками, например, апроксимировать и не жужжать.
А если хорошо, то на кой нужен второй алгоритм?

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

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


S>>Процесс или поток?
S>В СУБД используется термин "процесс".

S>>U блокировка это блокировка намерений. Так в примере с X блокировкой И U и S прекрасно пройдут без проблем и когда будет переход U->X нужно будет только подождать окончания S блокировок совместимые с U блокировками, т.к. транзакции начатые после окончания U блокировки будут блокированы. Хотя и здесь может ждать подводный камень, когда в момент U->X какая ни будь читающая транзакция не начнет
S>> читать блокируемые записи.
S>Не надо мне рассказывать, что такое блокировки. Поверьте мне, ничего нового вы не расскажете.
S>Вопрос в чём?

S>>Опять же давай абстрагируемся от БД и перейти на программирование для синхронизации одновременно выполняющихся потоков. Пусть U блокировка это расширенный ReaderWriterLock который кроме
S>>AcquireReaderLock, AcquireWriterLock имеет метод AcquireUpdaterLock которые можно применять к любому объекту и соответственно. И предположим ситуацию когда на записи 1,2,3,4 будут применяться блокировки но в разных последовательностях.
S>Ну, и в чём вопрос?

Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.

Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
Если же мы применим блокировки и AcquireReaderLock когда дата начала транзакции меньше даты окончания U Блокировки, мы гарантируем что новые S блокировки не будут конфликтовать, а старые придется подождать.
С учетом, того если конечно старые S блокировки, ранее не учавствовавшие в блокировке записей U транзакции примутся за чтение любых записей когда уже начался переход U -> X.

Лучше всего откатывать все такие S транзакции, в том числе и из-за соображения что записи вернут заведомо устаревшие данные.

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

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

S>> Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.

E>Если общий работает плохо, то на кой он нужен вообще? Лучше уж тогда всё прямоугольниками, например, апроксимировать и не жужжать.
E>А если хорошо, то на кой нужен второй алгоритм?
Алгоритмы имеют свойство модифицироваться и легче поддерживать специализированные. Общий может прекрасно работать, но долго. Как я уже тебе показывал раскрой кожи там все намного сложнее чем прямоугольники.
А общий будет применяться для фигур без специализации например при доводке более общих алгоритмов.

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

S> Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
S>Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
S>Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.
Правильно.

S>Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
Поток мыслей неясен. Совершенно непонятно, зачем вы заменяете X на U.
U призвана починить ровно одну ситуацию: когда есть некая частая процедура, которая сначала получает S блокировку на ресурс, а потом, чуть позже, получает X блокировку на тот же ресурс.
Запуск двух экземпляров такого процесса приводит к дедлоку с большой вероятностью: оба получат S, и оба встанут при конверсии в X.
Чинится это захватом U вместо S. Не X на U! Заменить X на U нельзя, так как защищаемая X операция — запись. Из-за совместимости U и S читатели будут рисковать прочитать незакоммиченное значение

S>Лучше всего откатывать все такие S транзакции, в том числе и из-за соображения что записи вернут заведомо устаревшие данные.
Лучше всего почитать учебники по СУБД, например Бернстайна.

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

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

S>> Предположим, что AcquireUpdaterLock блокирует AcquireWriterLock,AcquireUpdaterLock, а AcquireReaderLock может блокироваться позже некоторого времени.
S>>Предположим, что сначала мы применять записи к записям 1,2,3,4 и применить к ним AcquireWriterLock, одновременно к эти записям но в последовательности 4,3,2,1 идет другой поток и блокирует AcquireReaderLock
S>>Первый например успел заблокировать 4,3 а второй 1,2 и соотвественно первый не может получить записи 3, а второй к 1. Дид лук.
S>Правильно.

S>>Теперь вместо AcquireWriterLock применяем AcquireUpdaterLock но без блокировки AcquireReaderLock позже установки всех блокировок, при этом вариант при переходе из U в X не гарантирует, что что записи будут блокированы новой читающей транзакцией.
S>Поток мыслей неясен. Совершенно непонятно, зачем вы заменяете X на U.
S>U призвана починить ровно одну ситуацию: когда есть некая частая процедура, которая сначала получает S блокировку на ресурс, а потом, чуть позже, получает X блокировку на тот же ресурс.
S>Запуск двух экземпляров такого процесса приводит к дедлоку с большой вероятностью: оба получат S, и оба встанут при конверсии в X.
S>Чинится это захватом U вместо S. Не X на U! Заменить X на U нельзя, так как защищаемая X операция — запись. Из-за совместимости U и S читатели будут рисковать прочитать незакоммиченное значение
Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать. Типичный случай работы например в 1С. U блокировкой я заблокирую другие U и X блокировки, а сам буду читать совместно с S блокировками.
Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.


S>>Лучше всего откатывать все такие S транзакции, в том числе и из-за соображения что записи вернут заведомо устаревшие данные.
S>Лучше всего почитать учебники по СУБД, например Бернстайна.
За книгу спасибо. Обязательно почитаю.

Здравствуйте, Serginio1, Вы писали:
S> Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать.
То есть у вас сначала была X на всё время транзакции, а вы заменяете её на U, а затем X?
Ну да, это само работает.

S>Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.
Нет, этих дивидендов получить не удастся. Как только у вас есть захват во встречном порядке двух (или более) ресурсов, то никакими ухищрениями вы от дедлока не избавитесь.
U лечит только дедлоки на единичном ресурсе.
Того же эффекта можно добиться, вообще отказавшись от апгрейда локов — то есть вместо S(R1), .... X(R1)... сразу хватать X(R1).
И единственный недостаток такого артиллерийского приёма — это блокировка чисто-S транзакций в течение первой фазы процесса, т.е. снижение concurrency.
Вот с ним и борются U-блокировки.
А вы пытаетесь построить комбинацию из версионника и блокировочника. Именно версионники используют сравнение "дат транзакций" для разруливания конкурентного доступа.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Я заменяю X на U для того, чтобы сначала читать, а затем уже записывать.
S>То есть у вас сначала была X на всё время транзакции, а вы заменяете её на U, а затем X?
S>Ну да, это само работает.

S>>Но из этого можно еще получить дивиденды если запретить чтение S блокировками с датой больше даты окончания U блокировки, что бы исключить ситуацию с лил локами, а так же выдавать более точные данные.
S>Нет, этих дивидендов получить не удастся. Как только у вас есть захват во встречном порядке двух (или более) ресурсов, то никакими ухищрениями вы от дедлока не избавитесь.
S>U лечит только дедлоки на единичном ресурсе.
S>Того же эффекта можно добиться, вообще отказавшись от апгрейда локов — то есть вместо S(R1), .... X(R1)... сразу хватать X(R1).

S>И единственный недостаток такого артиллерийского приёма — это блокировка чисто-S транзакций в течение первой фазы процесса, т.е. снижение concurrency.
S>Вот с ним и борются U-блокировки.

S>А вы пытаетесь построить комбинацию из версионника и блокировочника. Именно версионники используют сравнение "дат транзакций" для разруливания конкурентного доступа.

Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
Ну в версионнике хранятся предыдущие версии и там вообще нет кучи конфликтов. Просто у такого подхода 2 премущества это уменьшение конфликта при U->X и второе это чтение S более актуальных данных.
Просто подход высказанный на SQL.RU мне понравился.

Заметьте не я это предложил

Хотя близкие идеи ворошились в моей голове.

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

S>Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
И в "вашем" подходе тоже не избавимся. К тому же помните, что удержание S-локов применяется на уровне изоляции RR, а в RC они отпускаются по мере продвижения чтения. Поэтому к моменту, когда "читатель" запросит S-лок на 4, залоченный в X, он уже отпустит S-лок на 1, 2 и 3. Поэтому "писатель" спокойно сконвертирует свой U-лок на 3 в X и поедет дальше, а читатель останется ждать окончания транзакции писателя.

SS> Хотя близкие идеи ворошились в моей голове.
Вы просто не понимаете, зачем предлагается решение на SQL.RU.
Оно решает редкую проблему: когда у меня есть транзакция, висящая на апгрейде U->X, и при этом у меня так много читателей, что их времена удержания локов перекрываются. То есть читатель1 читает ресурс, потом ресурс читает читатель2, и только теперь читатель1 отпускает лок. Но к моменту, когда читатель2 отпустит свой лок, уже прибежал читатель3 и захватил свой S-лок.
Мне всех читателей перечислять, или и так понятна природа проблемы?

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

Дата: 05.04.13 12:38

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

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

S>>Но при этом мы не избавимся от большей части дид локов когда S читает 123456, а U->X 654321
S>И в "вашем" подходе тоже не избавимся. К тому же помните, что удержание S-локов применяется на уровне изоляции RR, а в RC они отпускаются по мере продвижения чтения. Поэтому к моменту, когда "читатель" запросит S-лок на 4, залоченный в X, он уже отпустит S-лок на 1, 2 и 3. Поэтому "писатель" спокойно сконвертирует свой U-лок на 3 в X и поедет дальше, а читатель останется ждать окончания транзакции писателя.
Ну в итоге то мы хотим наложить блокировку RR. В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка. Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочитать данные в режиме RR, либо например когда использыется несколько регистров по одному измерению делается регистр сведений и по нему ставится блокировки. Это дает возможность сократить количество блокированных записей.
Но это так отступление.Просто есть куча регистров где используется постоянное чтение, которые изменяются с достаточно малой переодичностью. И вот U блокировки с возможностью X для S блокировок с датой начала более даты окончания U блокировки увеличила бы скорость проведения и уменьшила конфликты.
У меня сейчас нет 8 ки а то можно было бы посмотреть в профайлере что выдает
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Разделяемый;
ЭлементБлокировки.УстановитьЗначение("Номенклатура",Товар);
ЭлементБлокировки.УстановитьЗначение("Склад",Склад);

SS>> Хотя близкие идеи ворошились в моей голове.
S>Вы просто не понимаете, зачем предлагается решение на SQL.RU.
S>Оно решает редкую проблему: когда у меня есть транзакция, висящая на апгрейде U->X, и при этом у меня так много читателей, что их времена удержания локов перекрываются. То есть читатель1 читает ресурс, потом ресурс читает читатель2, и только теперь читатель1 отпускает лок. Но к моменту, когда читатель2 отпустит свой лок, уже прибежал читатель3 и захватил свой S-лок.
S>Мне всех читателей перечислять, или и так понятна природа проблемы?
Это ничем не отличается от просто X. С точки зрения ReaderWriterLock.AcquireWriterLock просто ставит в очередь всех кто хочет иметь доступ к записи.
ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.

Здравствуйте, Serginio1, Вы писали:
S>Ну в итоге то мы хотим наложить блокировку RR.
Нет такой блокировки.
S> В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
S> первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка.
То есть это Shared + HoldLock?

S>Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочитать данные в режиме RR, либо например когда использыется несколько регистров по одному измерению делается регистр сведений и по нему ставится блокировки. Это дает возможность сократить количество блокированных записей.
S>Но это так отступление.Просто есть куча регистров где используется постоянное чтение, которые изменяются с достаточно малой переодичностью. И вот U блокировки с возможностью X для S блокировок с датой начала более даты окончания U блокировки увеличила бы скорость проведения и уменьшила конфликты.
Простите, но после окончания U блокировки любые другие блокировки уже не будут её учитывать.
Вы что-то катастрофически путаете.

S>Это ничем не отличается от просто X. С точки зрения ReaderWriterLock.AcquireWriterLock просто ставит в очередь всех кто хочет иметь доступ к записи.
Это отличается тем, что а) я могу получить U и начать читать, не дожидаясь, пока все читатели уйдут и б) читатели могут продолжать получать S, пока я не сконвертился в X.

S>ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.
Непонятно, что и за счёт чего вы увеличите. Кто-то из нас катастрофически не понимает возможные последовательности событий при выполнении транзакций. Смею полагать, что это не я.

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

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


S>>> Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.

M>>Такой программист отправляется пешим ходом в первый класс. Потому что у нормального программиста будет метод «ПовернутьНа90Градусов(по-или-против-часовой)», общий для всех фигур (на плоскости), но реализуемый по-разному разными фигурами
S> Угу осталось добавить вокруг какой точки. Для прямоугольного треугольника это может быть только одна точка,

С какого перепугу только одна?

S>с ограинчением расположения треугольника в 4 положениях.

С какого перепугу ограничено только 4 положениями?

S> Спасибо за предложение. Пошел учиться

Именно. Это, вообще-то, общая задача, одинаково решаемая для любых многоугольников: поворот фигуры на N градусов вокруг точки Z. Но только школьникам хочется реализовывать никому не нужный специальный метод «повернуть-треугольник-на-90-градусов», рассказывая сказки про «ах-ах-ах, в прямоугольном треугольнике только одна точка, вокруг которой он может поворачиваться».

Ликбез: http://www.youtube.com/watch?v=U4Hv494HwrQ

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

S>Здравствуйте, Serginio1, Вы писали:
S>>Ну в итоге то мы хотим наложить блокировку RR.
S>Нет такой блокировки.
S>> В 1С есть такое понятие как управляемые блокировки и их типы РежимБлокировкиДанных.Разделяемый и РежимБлокировкиДанных.Исключительный
S>> первый действует так как с хинтом repeatableRead второй эХклюзивная блокировка.
S>То есть это Shared + HoldLock?
WITH(REPEATABLEREAD) например http://www.sql.ru/forum/actualthread.aspx?tid=1009095

S>>Сама транзакция в изоляции RC. Этим постоянно пользуюсь когда сначала нужно прочи
S>>ReaderWriterLock.AcquireWriterLock аналог UpgradeUpdaterLockToWriterLock должен просто изменить U->X, но так как для новых записей на блокировку нет, а старые уже в большинстве случаев могут уйти мы реально увеличим скорость проведения учитывая время на чтение в этой транзакции.
S>Непонятно, что и за счёт чего вы увеличите. Кто-то из нас катастрофически не понимает возможные последовательности событий при выполнении транзакций. Смею полагать, что это не я.
Давай посчитаем например время записывающей транзакции состоит из времени чтения Х и времени записи Y = Z.
Так с моей блокировкой время чтения может быть равно времени текущий читающих транзакция блокировавших записи при этом время транзакции останется Z.
При X и U по твоей методике будет Z+ время ожидания снятия S блокировок и может быть соизмеримо с временем чтения читающей транзакции то есть время будет ~ 2Х+Y

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

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

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


S>>>> Метод Начертить будет один для всех. А вот метод ПовернутьТреугольникНа90Градусов только для треугольника.

M>>>Такой программист отправляется пешим ходом в первый класс. Потому что у нормального программиста будет метод «ПовернутьНа90Градусов(по-или-против-часовой)», общий для всех фигур (на плоскости), но реализуемый по-разному разными фигурами
S>> Угу осталось добавить вокруг какой точки. Для прямоугольного треугольника это может быть только одна точка,

A>С какого перепугу только одна?
То есть можно одновременно поворачивать вокруг двух точек?
S>>с ограинчением расположения треугольника в 4 положениях.

A>С какого перепугу ограничено только 4 положениями?

S>> Спасибо за предложение. Пошел учиться

A>Именно. Это, вообще-то, общая задача, одинаково решаемая для любых многоугольников: поворот фигуры на N градусов вокруг точки Z. Но только школьникам хочется реализовывать никому не нужный специальный метод «повернуть-треугольник-на-90-градусов», рассказывая сказки про «ах-ах-ах, в прямоугольном треугольнике только одна точка, вокруг которой он может поворачиваться».
А зачем N градусов если известно положение рядом стоящей фигуры. Сколько свободного пространства останется если к стророне прямоугольника присоединиться углом а не стороной.


A>Ликбез: http://www.youtube.com/watch?v=U4Hv494HwrQ

M>>>>Такой программист отправляется пешим ходом в первый класс. Потому что у нормального программиста будет метод «ПовернутьНа90Градусов(по-или-против-часовой)», общий для всех фигур (на плоскости), но реализуемый по-разному разными фигурами
S>>> Угу осталось добавить вокруг какой точки. Для прямоугольного треугольника это может быть только одна точка,

A>>С какого перепугу только одна?
S>То есть можно одновременно поворачивать вокруг двух точек?

Где я говорю про одновременно?

S>>> Спасибо за предложение. Пошел учиться

A>>Именно. Это, вообще-то, общая задача, одинаково решаемая для любых многоугольников: поворот фигуры на N градусов вокруг точки Z. Но только школьникам хочется реализовывать никому не нужный специальный метод «повернуть-треугольник-на-90-градусов», рассказывая сказки про «ах-ах-ах, в прямоугольном треугольнике только одна точка, вокруг которой он может поворачиваться».
S> А зачем N градусов если известно положение рядом стоящей фигуры.

Потому что это — общая задача, одинаково решаемая для любого многоугольника. Что из выделенного тебе непонятно?

S> Сколько свободного пространства останется если к стророне прямоугольника присоединиться углом а не стороной.

Какая разница? Это останется задачей «повернуть многоугольник на N градусов вокруг точки Z».