Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Разницы нету, читайте пред. ветки... 06.08.05 14:09 Число просмотров: 1789
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 06.08.05 14:11 Количество правок: 2
|
> По поводу идеи с Sleep() - Фиговая идея.
Посмотрим...
> При обращении к объекту данных будет производиться ожидание
> снятия с него блокировки. Кстати время ожидания
> регулируется, если это поможет, конечно.
Регулируется... Даже если поставить 1 сек., то ровно 1 сек. будет один из процессоров сервера загружен на 100%. Дальше диалоговое окно, нервный щелчок пользователя "Повторить", и всё сначала... А когда пользователей 60 человек толпятся на серваке?
> Теперь вопрос. Что будет если начнется "тяжелая" транзакция
> с блокировкой некоторого объекта. Будет вызываться
> Sleep(100) до тех пор, пока объект не разблокируется, а в
> перерывах мы будем проверять состояние блокировки объекта
> или будем ругаться на пользователя матом. :)
Всё будет хорошо, я немного Вас не понимаю...
|
|
<job>
|
Есть работа в тему Reverce Engineering, Disasembling, Deep Crack. 29.07.05 13:50
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 30.07.05 12:02 Количество правок: 2
|
Есть екзешник программы, которая по сути виртуальная машина для особого языка, небезызвестная 1С Бухгалтерия седьмой версии.
Цель: поправить его таким образом, чтобы при возникновении особых ситуаций (взаимные блокировки пользователей, вызывающие паразитные быстрые циклы проверки флага блокировки, съедающие 100% процессорного времени), в вышеуказанном цикле исполнялся бы вызов функции Windows API Sleep(100), который коренным образом бы исправил проблему.
Цену обговорим в процессе. Кидайте на мыло alex_wh (<AТ>) mail.ru
|
|
Вообще-то проблема блокировок на 99% решается оптимизацией... 03.08.05 19:08
Автор: БЖ Статус: Незарегистрированный пользователь
|
|
Вообще-то проблема блокировок на 99% решается оптимизацией конфигурации, прямого доступа к таблицам , быстрыми регистрами, административными мерами (разделение базы на несколько "распределенных", настройка репликации) и т.п.
|
| |
Оптимизация не будет поспевать за изменениями в конфигурации... Жизнь сложна и непредсказуема... Это считай пристёгивать к себе спеца-подрядчика-«оптимизатора» на вечные времена ;-) 05.08.05 15:55
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 05.08.05 15:58 Количество правок: 2
|
|
|
| | |
Типовая конфигурация что ли? 05.08.05 16:45
Автор: БЖ Статус: Незарегистрированный пользователь
|
А, наверное речь идет о типовой конфигурации? тогда согласен, 1С не шибко заморачивается по поводу оптимизации кода. Упор делается на расширение возможностей конфигурации, часто невостребованных. В связи с этим и возникает необходимость брать в штат 1С-кодера.
---
По поводу идеи с Sleep() - Фиговая идея.
При обращении к объекту данных будет производиться ожидание снятия с него блокировки. Кстати время ожидания регулируется, если это поможет, конечно.
Теперь вопрос. Что будет если начнется "тяжелая" транзакция с блокировкой некоторого объекта. Будет вызываться Sleep(100) до тех пор, пока объект не разблокируется, а в перерывах мы будем проверять состояние блокировки объекта или будем ругаться на пользователя матом. :)
|
| | | |
Разницы нету, читайте пред. ветки... 06.08.05 14:09
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 06.08.05 14:11 Количество правок: 2
|
> По поводу идеи с Sleep() - Фиговая идея.
Посмотрим...
> При обращении к объекту данных будет производиться ожидание
> снятия с него блокировки. Кстати время ожидания
> регулируется, если это поможет, конечно.
Регулируется... Даже если поставить 1 сек., то ровно 1 сек. будет один из процессоров сервера загружен на 100%. Дальше диалоговое окно, нервный щелчок пользователя "Повторить", и всё сначала... А когда пользователей 60 человек толпятся на серваке?
> Теперь вопрос. Что будет если начнется "тяжелая" транзакция
> с блокировкой некоторого объекта. Будет вызываться
> Sleep(100) до тех пор, пока объект не разблокируется, а в
> перерывах мы будем проверять состояние блокировки объекта
> или будем ругаться на пользователя матом. :)
Всё будет хорошо, я немного Вас не понимаю...
|
|
Думаю несложно, но не думаю что будет толк [updated]. 29.07.05 14:15
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 29.07.05 14:24 Количество правок: 1
|
Конкретно 1C "на зуб" я не пробовал, но если там нет каких-нибудь защит типа v-box, то предположительно это несложно.
Но с другой стороны не ясно, почему возникают такие loop-эффекты? При разумном кол-ве конкурирующих потоков синхронизация на базе CRITICAL_SECTION неплохо от этого спасает. В случае очень большого кол-ва потоков время большей частью тратится не на loop-циклы, а на переключение между потоками и scheduling. И подобными правками кода ситуацию не исправить. Что говорит FAQ и тех.поддержка разработчика?
[updated]
Если у разработчиков местами кривые руки, то можно попробовать повставлять SwitchToThread() в нужные места. Если нужна функциональность только под W2K/XP (не под 95/98/Me) могу взяться. Как минимум нужен набор файлов, например дистрибутив + база + клиент/тест (а еще лучше просто архив) на котором ситуация легко воспроизводится. Если подготовишь сегодня до 21:00 MSK, то может сделаю за эти выходные.
|
| |
В 1С ситуация = хуже некуда... 03.08.05 12:43
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 03.08.05 16:01 Количество правок: 2
|
Решил ответить в форум, может кто-то что-нибудь добавит.
Удалось немного пообщаться с некоторыми (бывшими) разработчиками 1С. Стало ясно, почему с многопользовательским режимом во всех версиях 1С очень плохо. Опишу подробно, чтобы всем было ясно, в чем дело. Сразу оговорюсь, я не программировал для 1С (бог миловал), и не знаком с её внутренностями. Всё что написано ниже – мое видение ситуации на основе информации, полученной от нескольких разных людей. Разобраться было интересно, чтобы выяснить, почему 1С никак не решает эти проблемы.
Изначально ядро 1С разрабатывалось с прицелом на «персональность», про многопользовательские режимы никто даже не думал. Соответственно организация разделения доступа (блокировок) не продумывалась, язык и engine имели предметно-чайниковую (около бухгалтерскую) направленность. Архитектура делалась по принципу – сейчас сделаем как проще, потом разберемся и доделаем.
Первые версии работали под DOS в однопользовательском режиме, с разделением доступа проблем нет. Для организации двух-трех рабочих мест достаточно файл-сервера и простейшего итеративного механизма блокировки. Работает он так: каждый из конкурирующих процессов, «не задумываясь», пытается заблокировать нужные ему таблицы, по очереди, но в любом порядке. Если удается поставить все блокировки, то выполнение продолжается. Если хотя-бы одна из таблиц уже используется другим пользователем, то уже установленные блокировки снимаются, и делается ещё одна итерация по «полному циклу». Если блокировки не удалось «расставить» за N-ое кол-во попыток или за некоторый период времени, то возвращается код ошибки.
Такой подход:
1) Позволяет разработчикам никак не заботиться о порядке блокирования таблиц;
2) Тривиально реализуется в уже написанном «однопользовательском» коде;
3) Неплохо работает в Novell-подобных средах, при небольшом кол-ве пользователей;
4) Почти идеален для небольших фирм, где с 1С работают 1-2 бухгалтера и директор. Как правило, пользователи не замечают проблем с взаимными блокировками;
Разработчики 1С сделали так пошли «дальше». Чтобы при конфликте блокировок пользователи могли знать, почему им не дают работать, реализовали систему «флажков». Процесс блокировки дополнился установкой флажков вида «таблицы X, Y, Z заняты модулем A, который для пользователя B выполняет процедуру C». Это немного увеличило трафик блокировок, конкуренция за таблицу флажков стала критической, но если взять за правило блокировать первой таблицу с флажками, то это «бутылочное горлышко» было удобным местом мониторинга и немного упорядочивало очередность.
Потом стало ещё хуже. Разработчики системы и «программисты»-предметники наплодили кучу рецептов, шаблонов кода и «подходов» к реализации многих «бухгалтерских» подзадач. Во многих этих «кубиках-конструкторах» устанавливаются глобальные флажки-индикаторы, типа «генерировать отчеты А, Б и делать проводки С нельзя, потому, что происходит процесс D». Передергивание нескольких глобальных флажков даже при тривиальных операциях стало нормой. Снежный ком блокировок укатал всех, а SQL-серверы стали «спать» на журнале транзакций…
Поэтому 1С одинаково плохо работает, как на DBF-файлах, так и на SQL-транзакциях. Для избавления от итеративных блокировок нужно получать доступ к таблицам в строго определенном порядке (например отсортировав по названию). Соответственно на уровне языка должно быть заложена конструкция «начать транзакцию с доступом к таблицам A, B, C…». Сделать это не всегда возможно, обращение к «библиотечным» процедурам или методам объектов обычно порождает сложно-контролируемую вложенную активность.
По-хорошему выход только один – компилятор, который анализирует процедурно-объектную модель и строит списки таблиц используемых в каждой транзакцией. Либо двух проходное (на самом деле много проходное) выполнение. На первом проходе выявляются используемые объекты, потом они блокируются, и на втором проходе выполняется код. Проблема в доступе к таблицам по условию, их нужно либо блокировать все сразу, либо реализовывать спекулятивное выполнение и многопроходность (но в конечном итоге это снова приводит к итеративному механизму).
Я делал подобный engine в начале 90-х, поэтому отчасти помню проблему. Решить задачу с блокировками мне тогда так и не дали, ситуация и аргументы схожие – зачем делать то, без чего можно обойтись сейчас...
Перенос БД 1С на SQL (или другие СУБД) ничего не дает без ликвидации итеративного механизма блокировок и избавления от «дребезга» глобальных флажков. Или другими словами переписи огромного кол-ва кода 1С-приложений (ака конфигураций), переучивания людей и т.д. Самое главное – это нужно продать по-новой тем, кто уже обжегся. Делать этого конечно никто не будет, 1С – прежде всего дистрибьюторская фирма, которая продаёт, а не разрабатывает ПО.
Как резюме – решить проблему толком не возможно. Нужно вместо 1С сделать как минимум 2С. В конкретной описанной ситуации (waste-loops while locking) можно попробовать подменить db-engine.dll и пропускать всю активность «через» глобальный семафор. Это даст гарантию, что в waste-loop попадёт не более одного CPU, но и только один будет работать с данными (имеем 1C на DBF в Terminal Server). Но есть большая вероятность (даже очень большая) получить dead-lock. Нужно пробовать...
|
| | |
[UPD] хм.. 05.08.05 22:08
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 05.08.05 23:43 Количество правок: 7
|
Я еще больший ламер в 1С, тк у меня даже знакомых оттуда нету, так что о внутренностях могу судить только по этой ветке.
Спрашивается а почему нельзя было сделать так:
for(;;)
{
Лочим глобальный лок (EnterCriticalSection(&global_lock))
Делаем ReleaseSemaphore(sem1,1,0);
Поочредено пытаемся захватить и залочить все нужные ресурсы (WaitoFrSingleObject(res_mutex[i],0)==WAIT_OBJECT_0)
Если гдето обломались - разлочиваем всех уже залоченных. И ставим флаг успешного лока в false.
Если лок получился успешный - WaitForSingleObject(sem1,0);
Разлочиваем глобальный лок (LeaveCriticalSection(&global_lock))
Если лок получился успешный - break;
Иначе делаем WaitForSingleObject(sem2,INFINITE); и продолжаем цикл
}
Когда лочный цикл сработал:
{
работаем с ресурсами (пишем,читаем), при освобождении каждого ресурса делаем:
EnterCriticalSection(&global_lock);
while(WaitForSingleObject(sem1,0)==WAIT_OBJECT_0)ReleaseSemaphore(sem2);
LeaveCriticalSection(&global_lock);
}
Просто надо сделать не глобальный лок, а чтобы процедура лочения всех ресурсов сама по себе была атомарной. Тогда не будет дребезга и дедлоков. Недостатком такого метода будет то что при разлочке каждого ресурса лочный цикл будет прокручиваться один раз для каждого ожидающего потока, что легко лечится введением ресурсных индексов для sem1 и sem2 - при этом прокручиваться будут только те потоки, которые заинтересованы в освободившемся ресурсе. А если еще немного подумать то можно организовать очередь, в которой поток которых хочет захватить ресурсы A, E, G - - вначале быстренько проверяет в критической секции их доступность и если ктото занят - пушит в list этакую структурку - "хочу A, E, G, когда они освободяться прошу разбудить меня вот этим Event'ом". А при разлочке любого ресурса анализировать очередь, кому там что надо, и самому "старому" подходящему кандидату сигналить семафор. А потому другому старому если таковой найдеться. И так далее. Естественно процедурку проверки и сигналения семафоров - в критическую секцию. В туже самую что и начальную проверку потоком доступности нужных ему ресурсов перед засыпанием.
Но это конечно к разработчикам 1С, нежели к кракерам..
ЗЫ Эх блин почему многие программеры так хреново соображают в многопоточности..
|
| | | |
Это всё к разработчикам 1С. Они — монстры :-) А у меня исходников нету, чтобы подправить... 08.08.05 07:42
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
любопытно off 04.08.05 20:53
Автор: vaborg <Israel Vaborg> Статус: Elderman
|
Я не очень разбираюсь в этом вопросе, но мне просто интересно
почему нельзя реализовать аналогично SourceSafe, которая вполне сносно
управляет доступом к файлам. Более того, есть же CVS или subversion,
где можно посмотреть как это сделано.
|
| | | |
Ну это как-то совсем off-topic 04.08.05 21:46
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Во всех Version-Control (cvs, subversion, sourcesafe, perforce, etc...) блокировка делается только при изменении файла и только сервером при обработке запросов.
С базами данных это несравнимо сложнее. Для возможности одновременной обработки запросов от нескольких процессов (пользователей) и параллельной обработки, придумали массу видов блокировок. Отдельные записи (строки), иногда столбцы, таблицы и т.д. Поэтому сравнение с source-contorl совершенно неприменимо...
Хотя, в бытность продвижения Oracle 8i, я до хрипоты спорил с одним из "продвигалетей". Убеждая его, что для "малого бизнеса" решение с единым глобальным lock-ом (single-write/multi-read) на уровне БД (как совокупности таблиц) и хостом с одним-двумя CPU, в целом будет лучше.
По сути это я и предложил сделать в обсуждаемом случае. Проблема в том, что нельзя сделать достаточно эффективно, без разбирательства с семантикой ООП-доступа к БД из внутренностей 1С. Чего делать очень не хочется, там более 100 функций-методов.
Основная текущая реальная проблема в очень многих системах типа 1С в том, что в разные моменты времени нужно блокировать разное подмножество объектов (таблиц). И благодаря ООП, стремлению к универсальности и ленивости/тупости прикладных программистов, это множество объектов становится определимо только во время выполнения кода. Поэтому "классическая" тактика разделения доступа непременима (dead-lock), а из всего другого самый легкий выбор - итеративный "тупизм".
|
| | | | |
спасибо, просто и понятно :) 05.08.05 16:34
Автор: vaborg <Israel Vaborg> Статус: Elderman
|
|
|
| | | | |
Пусть тупизм... Пусть ждут все! Но эта... В ожидании зачем кушать 100% времение проца? ;-) 05.08.05 15:53
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
