Не только потоки Текст научной статьи по специальности «Компьютерные и информационные науки»

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