CC BY
40
phpMyAdmin
& 14 •& f] @
| [Недавние таблицы)... |^||
Ш
I client
В ats И Cities g clientjnfo И coords g services g streets g users
1 @ Создать таблицу
d! 127.0.0.1 » В client
Щ Структура Таблица a
О SQL -4 Поиск Ql Запрос по шаблону В Экспорт В Импорт Операции л=| Привилегии Процедуры ^ Ещё
Действие
Строки igi Тип Сравнение
О ats g Обвор |i^ Структура ^ Поиск *с Вставить ^ Очистить t
О cities g Обзор ^ Структура 45 Поиск Вставить gi Очистить (
0 clientjnfo g Обзор Структура _( Поиск з^с Вставить Ej^l Очистить t
□ coords g Обзор Структура 4 Поиск *с Вставить @1 Очистить t
0 services g Обзор Структура ^ Поиск Вставить @ Очистить i
О streets g Обзор ^ Структура Поиск jfc Вставить ^ Очистить (
0 users g Обзор §^| Структура ^ Поиск *с Вставить ^ Очистить t
7 таблиц Всего
^___ Отметить все ! Снять выделение / Отметить требующие оптимизации
i Удалить бз MylSAM utf8_general_ci 6
} Удалить s MylSAM utf8_general_ci 2
> Удалить 1-764 MylSAM utf8_general_ci 147
& Удалить i г 707 MylSAM utf8_general_ci ее i Удалить = MylSAM utf8_general_ci 2
i Удалить юс MylSAM utfS general ci s
i Удалить s MylSAM utf8_general_ci 2
3.649 innoDB utf8_general_ci 235
Размер Фрагментировано
6 КБ -
1 КБ
з :<б
7 КБ 1 КБ 1 КБ 7 КБ 7 КБ
I С отмеченными:
в
I Версия для печати^ Словарь данных
|—| Щ Создать таблицу |—
Рис.3 - phpMyAdmin
20 Байг 144 Eaiii
S36 Байе? 616 Байт
Разработку программного кода и визуальное проектирование можно выполнить с использованием Nootepad++ и ознакомительной версии Adobe Dreamweaver CS6 (HTML-редактор). При редактировании Adobe Dreamweaver показывает готовую страницу в режиме WYSIWYG (что видишь, то и получишь), что является достаточно удобным и быстрым для создания web-интерфейса. Данные программные продукты полностью совместимы между собой и с установленной операционной системой [4].
Разрабатываемая CRM-системы позволит: повысить производительность труда
активных продавцов, создать базу данных с разграничением прав доступа. Внедрение информационной системы значительно облегчает данную работу, поскольку создается база данных, которая позволит оперативно отражать информацию. Также значительно облегчается сам процесс изменения и ведения бумажной документации, поскольку основные элементы операций автоматизированы и выполняются по достаточно несложному алгоритму, в результате чего экономится время, человеческие ресурсы, оперативно поступает информация и повышается качество работы в целом.
Литература
1. Keith Brandt. When Bad Harmonics Happen to Good People. - OSP. November 2007.P.- 16.
2. Горев А. Эффективная работа с СУБД - М.: Инфра, 2000 г., 504 с.
3. Кузнецов С.Д. СУБД (системы управления базами данных) и файловые системы.- М: Майор, 2001 г
4. Никифоров С.В. Введение в сетевые технологии: Элементы применения и
администрирования сетей: Учеб. пособие. - М.:Финансы и статистика, 2010. - 224 с
УДК 004.04
НЕ ТОЛЬКО ПОТОКИ
Дагаев Дмитрий Викторович, Директор по АСУТП, ОАО «ДЖЭТ», Россия, Москва,
dvdagaev@,mail.ru
Задачи и сопрограммы
При разработке серверных приложений часто встает вопрос необходимости одновременной работы и взаимодействия нескольких подзадач. Это сродни многозадачности, в [1] говорится о "разновидности процесса внутри самого процесса". Как решения для серверной задачи предлагаются 3 варианта:
• многопоточный процесс;
• однопоточный процесс;
• параллельная работа с неблокирующими системными вызовами.
15
Там, где однопоточный процесс с блокирующими системными вызовами невозможен, обычно используется многопоточное программирование. Мы же будем рассматривать последний случай, который предполагает несколько нитей вычислений с сохраняемым состоянием у каждого, и события, по которым осуществляются переходы состояний. В качестве реализации предлагаются:
• задачи (Tasks), в которых нужно делать функцию перехода состояний в стиле конечного автомата, и возвращающие управление;
• сопрограммы (Coroutines), позволяющие выходить из произвольной точки кода процедуры и возвращаться на следующий за ней оператор.
Для каждого объекта-задачи вводится состояние и функция перехода, которая для простого примера печати натуральных чисел выглядит так:
PROCEDURE Do (t: Task);
BEGIN IF t.count < t.max THEN INC(t.count); Log.Int(t.count); Log.Ln; END
END Do;
Функция должна быть написана таким образом, чтобы при периодическом вызове изменять состояние t. count и возвращать управление.
Вариант с объектом-сопрограммой более универсален:
PROCEDURE Do (t: Cotoutine); VAR j: INTEGER;
BEGIN j := 0; WHILE TRUE DO INC(j); Log.Int(j); Log.Ln; Co.Yield END
END Do;
Функция содержит только точку выхода Co.Yield и возвращается при следующем вызове на следующий за ней оператор.
Использование сопрограмм имеет долгую историю. По утверждению Кнута [2], "подпрограмма является частным случаем сопрограммы". Сопрограммы широко использовались в ассемблерных проектах, Вирт ввел сопрограммы в язык Модула-2. Работа подпрограммы определяется более строгой дисциплиной LIFO, при которой выделяется стековая область для локальных переменных каждого экземпляра подпрограммы (детально: записывает в стек адрес следующей команды, переходит по адресу процедуры, выделяет в стеке место для локальных переменных). При выходе из подпрограммы эта область освобождается (помещая в стек возвращаемое значение и переходя к следующей команде).
В сопрограммах такой дисциплины нет, для их использования нужны 3 свойства [3]:
• локальные данные сохраняются между успешными вызовами;
• выполнение приостанавливается в определенных точках разрыва, при дальнейшей передаче управление переходит на следующий оператор;
• управление может передаваться от одной сопрограммы к другой, при этом вызывающая сопрограмма приостанавливается. Последнее свойство запрещено использовать для решения задач разделения времени, чтобы обеспечить герметичность взаимодействия.
Оператор Yield осуществляет как раз этот выход из процедуры с последующим возвратом на следующий за ним оператор. Это достигается путем отдельного сохранения всего стека выполнения каждой сопрограммы в предварительно отведенной памяти, а также состояния регистров (указателя стека, счетчика команд, и др.). При вызове Yield происходит такой переход с переключением контекстов, но сопрограммы считаются легковеснее потоков, т.к. последние, как минимум, имеют дополнительные издержки на штатный планировщик.
Для управления задачами и сопрограммами потребовалось реализовать планировщик на уровне пользовательского процесса, который и осуществляет механизмы переключения.
Объектная модель планировщика
Разработанная модель берет свое начало в [4], при этом пользовательская задача наследуется от Task и реализует состояния и функцию перехода Do, либо пользовательская
16
сопрограмма наследуется от Coroutine и реализует вызываемую планировщиком функцию Do с точками разрыва. В соответствие с заложенными принципами, пользовательский тип наследуется от типа, определенного в Tasks, и реализуется виртуальная функция Do. Т.е. есть наследование типов и нет наследования реализации.
Построение основано на тройке классов Scheduler/Task/Dispatcher, предложенной в [4] как вариация обобщенной тройки Carrier/Rider/Link (другой вариацией является известная Модель/Вид/Контроллер). При этом иерархии классов Task-Coroutine-UserProgram (возможно, и Task-UserProgram) и Dispatcher-S_Dispatcher+Scheduler-S_Scheduler развиваются независимо.
Рис. 1 - Объектная модель планировщика
Первая группа отвечает за пользовательскую реализацию. В соответствии с принципом отделения абстракции от реализации пользовательская программа наследуется от типа Coroutine и остается одинаковой, несмотря на разные реализации сопрограммы на 2 компиляторах для 2 ОС каждый. Помимо реализации метода Do нужно также иметь в виду, что переходы на другие сопрограммы в режиме планировщика запрещены на уровне рантайма, а управление поведением сопрограмм (скажем, для защиты общих ресурсов) осуществляется с помощью семафоров и методов Resume, Suspend, SchedSleep.
Вторая группа S_Scheduler+S_Dispatcher представляет собой реализацию абстрактных типов Scheduler и Dispatcher, которая работает со списком задач S_TaskList, выбирая адрес, куда передается управление. Реализуется алгоритм циклического планирования с двумя уровнями приоритета. В зависимости от параметров планировщика, определяющих квоту времени, переход в точках разрыва может не осуществляться, если квота не выбрана.
17
Следует сравнить механизмы семафоров сопрограмм, с одной стороны, и считающиеся более структурированными мониторы Хоара-Хансена [1] и активные объекты, с другой [5]. Отсутствие вытесняющей многозадачности меняет поведение семафоров, т.к. вся сопрограмма превращается в «критическую область» в смысле Хансена или в эксклюзивную секцию активного объекта. Семафор определяет точку разрыва защищенной области, в которой сопрограмма будет находиться в состоянии активного ожидания:
BEGIN Do1; Co.SemDown(sem); Do2 END
Аналогичная секция активного объекта на языке Активный Оберон [5] будет выглядеть:
BEGIN {EXCLUSIVE} Do1; AWAIT(sem>0); DEC(sem); Do2 END
Следует заметить, что активные объекты и мониторы разрабатывались на замену менее структурированным средствам синхронизации, в т.ч. семафорам. Но для сопрограмм эта неструктурированность уходит, причем это решается без дополнительных языковых средств.
Сравнение реализаций
Для языков Оберон-семейства BlackBox и XDS и операционных систем Linux и Windows сравнивались варианты реализации.
XDS подключает одинаковый для Linux и Windows библиотечный модуль COROUTINES, основные функции которого - старт и переключение:
COROUTINES.NEWCOROUTINE(RunProc, stack, ssize, coroutine); (* старт *)
COROUTINES.TRANSFER(from, coroutine); (* переключение *)
BlackBox использует функции работы с Fibers библиотеки Win32:
primary := WinApi.ConvertThreadToFiber(0);
fiber := WinApi.CreateFiber(ssize, RunProc, coroutine); (* старт *)
WinApi.SwitchToFiber(fiber); (* переключение *)
BlackBox для Linux использует для аналогичных целей контексты, подключая модуль CA как библиотеку libc CA[“libc.so.6”]:
context.uc stack.ss sp := stack;
context.uc stack.ss size := ssize;
rc := CA.makecontext(context, RunProc, 3, context , tmp context, coroutine); (* старт *)
rc := CA.swapcontext(tmp context, context) (* переключение *)
Были оценены времена переключений между сопрограммами по сравнению с временами переключения между потоками в реализации на C в тестовом примере с числом задач = 100.
Рис. 2 - Среднее время переключения между задачами, мкс
18
Приведенные диаграммы носят в большей степени качественный характер, т.к. реальные характеристики сильно зависят от оборудования, на котором производится тестирование. В нормальном случае переключение между заведомо более «тяжеловесными» потоками должно занимать большее время, поэтому дополнительные 40-70% времени для потоков представляются разумной цифрой. Только времена по переключению контекстов BlackBox для Linux отличаются в худшую сторону, в связи с чем можно посетовать на реализацию библиотеки контекстов в Linux или перейти на более низкий, ассемблерный уровень.
В качестве рекомендаций по применению следует иметь в виду несколько моментов. Эти данные соответствуют однопроцессорному аппаратному обеспечению, многопоточные приложения, в отличие от сопрограмм, распределяются по аппаратуре. Также, несмотря на полную защищенность Оберонов, их сборщики мусора не отслеживают локальные стеки сопрограмм, поэтому указатели как переменные в локальных стеках не должны оставаться последними адресатами памяти, что-то должно быть в «куче» или основной программе. Зато такой подход дает более гибкие способы управления планированием.
Литература
1. Э.Таненбаум. Современные Операционные Системы. 3-е изд. 2012.
2. Искусство программирования, том 1. Основные алгоритмы = The Art of Computer Programming, vol.1. Fundamental Algorithms. — 3-е изд. — М., 2006
3. George Frasier “Cross-Platform Coroutines in C++”, Dr.Jobbs, March 01, 2001
4. C.Szyperski "Insight-EthOS: An Object-Orientation in Operating Systems", 1992.
5. P.J. Muller. The Active Object System - Design and Multiprocessor Implementation. PhD thesis, ETH Zurich, 200
УДК 004.896
ПРОЕКТИРОВАНИЕ МНОГОАГЕНТНОЙ РАСПРЕДЕЛЁННОЙ СИСТЕМЫ СОЗДАНИЯ ПРОЕКТНЫХ РЕШЕНИЙ С ИСПОЛЬЗОВАНИЕМ СТРУКТУРНОФУНКЦИОНАЛЬНЫХ ЛИНГВИСТИЧЕСКИХ МОДЕЛЕЙ
Хородов Виталий Сергеевич, аспирант кафедры вычислительная техника, Ульяновский
государственный технический университет, Россия, г. Ульяновск, v.khorodov73@gmail.com
Введение
Современной парадигмой, нашедшей широкое применение в практике проектирования сложных технических объектов, является smart environment («умная» среда). При этом большое внимание уделяется построению среды взаимодействия, которая способствует совместной работе проектировщиков [1]. Одной из основных тенденций в развитии современных САПР является распределённая реализация проектных процедур проектировщиками, которые находятся на удалённом расстоянии друг от друга.
В настоящее время одним из факторов, характеризующих возрастание сложности процесса проектирования, является объем создаваемого кода на Hardware Description Language (HDL) языке и количество логических вентилей в проектируемых схемах.
Реализация связующего программного обеспечения (middleware level) - необходимый этап для организации взаимодействия между проектировщиками. Для размещений связующего ПО можно использовать облачные технологии, которые должны способствовать реализации системы распределённого проектирования.
В статье предлагается подход к построению системы распределённого проектирования, которая позволит создавать проектные решения с использованием структурнофункциональных лингвистических моделей (СФЛМ), в которой используется агентноориентированная технология. Обосновывается выбор агентно-ориентированной
19
