информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / job
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Типовая конфигурация что ли? 05.08.05 16:45  Число просмотров: 1834
Автор: БЖ Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
А, наверное речь идет о типовой конфигурации? тогда согласен, 1С не шибко заморачивается по поводу оптимизации кода. Упор делается на расширение возможностей конфигурации, часто невостребованных. В связи с этим и возникает необходимость брать в штат 1С-кодера.
---
По поводу идеи с Sleep() - Фиговая идея.
При обращении к объекту данных будет производиться ожидание снятия с него блокировки. Кстати время ожидания регулируется, если это поможет, конечно.
Теперь вопрос. Что будет если начнется "тяжелая" транзакция с блокировкой некоторого объекта. Будет вызываться 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
<"чистая" ссылка> <обсуждение закрыто>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach