Когда используются функции из библиотек Visual FoxPro FLL или стандартных компонент Windows DLL, которые созданы с помощью интерфейса Visual FoxPro API, существуют некоторые проблемы, которые вы должны учитывать при проектировании и разработке ваших Серверов. Существующий интерфейс Visual FoxPro API не в состоянии полностью определить какой из активных проектов (.dll) выполняет специфический, конкретный Запрос на обработку. Поэтому, существует потенциальная возможность ситуации (хотя достаточно редко) когда программный интерфейс API вызывает конкурирующий Запрос к рассматриваемому Серверу (.dll размещен в локальном процессе). Это может произойти в том случае, когда рассматриваемая библиотека FLL/DLL создана в другим сервере Visual FoxPro .dll (другими словами: предназначена для выполнения с другой библиотекой исполнение). Существует несколько решений, позволяющих избежать описанные выше потенциальные проблемы:

• Создание независимой копии многопоточной библиотеки исполнения (Multithreaded Visual FoxPro Run-Time Library), и размещение этой копии рядом с рассматриваемым Сервером, в одной папке. Сервер всегда начинает поиск необходимой компоненты сначала с текущей папки, далее в подкаталоге Windows System или в папке, где размещается сам Клиент VFP. При наличии в одной папке обслуживающей Его библиотеки исполнения, рассматриваемый Сервер не будет испытывать проблем с конкурирующими процессами, которые отсутствуют в описанной папке, иначе последние смогут перехватить обслуживающую библиотеку исполнения. Описанные выше Сценарий предполагается для многих случаев (автоматическое копирование-переименование библиотеки исполнения в папку запрашивающего обслуживания Сервера), поэтому существующий программный интерфейс API выполняет только Декларацию необходимых функций для многопоточной библиотеки исполнения Visual FoxPro.

• Ограничитесь в вашем Приложении одним Сервером (файлом типа .dll). Если вы используете несколько Серверов, модулей .dll,  (построенных из нескольких Проектов), то возникает потенциальная возможность возникновения конфликтов программного интерфейса API. Обратите внимание, что один Проект может содержать несколько Определений Классов с ключевой опцией OLEPUBLIC, в противном случае вам необходимо создавать для каждого OLEPUBLIC независимых Проект, а следовательно и модуль .Dll. Не забывайте, что на общедоступных Серверах (или Рабочих Станциях) другими пользователями могут устанавливаться другие обслуживающие Visual FoxPro COM, которые могут вступать в конфликт с вашим Сервером.

Многопоточная библиотека исполнения Visual FoxPro предназначается для масштабирования однопоточных локальных серверов Visual FoxPro (in-process servers). Хотя процессы масштабирования ваших серверов автоматически начинают обслуживать сервера в момент их загрузки, могут возникнуть некоторые Петли программного Кода (неявные ошибки), которые не позволят выполнить переключение между обслуживаемыми Процессами. Например, могут возникнуть ситуации  невозможности выхода из программного цикла DO WHILE. Если у вас возникают описанные выше проблемы с процессами масштабирования, вы можете включить в программный Код ваших модулей приводимый ниже фрагмент программного Кода, который вынуждает процессор переключиться на обработку другого Процесса:

	Копировать Код
DECLARE Sleep IN Win32API INTEGER SLEEP(0)

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

В представленном примере: метод А и метод В активируются Одновременно. В Одно-Поточной Компоненте, эти методы переконфигурируются в Очередь на обслуживание, поэтому метод B не начинает работать пока не закончился метод A. В условиях Много-Поточной  компоненты обслуживания рассматриваемые методы свободно конкурируют за обслуживание их Процессором.

Кроме того, общее время обслуживания Методов увеличивается за счет необходимых временных издержек по переключению процессора между обрабатываемыми процессами.

Основная проблема состоит в том, что оба метода (A и B) начинают обслуживаться в один момент времени.

Например, Если бы метод B "опрашивался" только три раза то момента его завершения, то пользователь почуствовал значительное оживление процесса обработки Запросов метода B — и только всего лишь небольшую задержку при обслуживании метода A.

Различные сценарии обслуживания Запросов с использованием Многопоточной компоненты показывают, что несколько коротких Запросов, которые сопоставимы с временем переключения Процессора между Задачами, обрабатываются достаточно эффективно — Например, в течение ожидания процессом выполнения операции Ввода/Вывода в файл  — другие "короткие" процессы могут быть быстро выполнены.

Если вы рассматриваете Приложение, выполняемое на однопроцессорной рабочей станции, имеющей высокие характеристики времени переключения между операциями блокирования обслуживающих процессов, то вы можете смело использовать главную библиотеку исполнения Visual FoxPro. Для многопроцессорных рабочих станций и приложений, которые выполняют сложные и не равнозначные функции вам рекомендуется рассмотреть варианты использования Многопоточной библиотеки исполнения Visual FoxPro, которая будет поддерживать ваши серверы .dll .

Для Приложений, построенных на модели Реентерабельности (возможности повторного входа в программу), существует вероятность возникновения следующих Событий:

1. Система обслуживания Потока выполняет программный (объектный) Код обслуживаемого Свойства или Метода.

2. Пока обслуживается Поток текущего свойства или метода, другой поток пытается обратиться к свойству или методу рассматриваемого объекта, согласно принципам Automation создается очередь на обслуживание — новые запросы устанавливаются в очередь перед последним Потоком на обслуживание рассматриваемого Объекта.

3. Прежде, чем поток достигает конца обслуживания, выполняется программный Код, который управляет переключением Процессора.

4. По принципу Automation для потока составляется новое Задание, которое представляет собой скомбинированную очередь на обслуживание данным потоком, выполнения программного кода Очереди.

Новый запрос на обслуживание может поступить от объекта, который уже был выполнен активным Потоком — в этом случае этот запрос также (второй раз) устанавливается в очередь на обслуживание — или аналогичный запрос может поступить от другого Процесса. Если второй Объект будет конкурировать, то он будет обработан перед первым Объектом. Если изменяются уровни приоритетов выполняемых модулей, то какой из рассматриваемых Объектов (очередников) получает управление - обработку невозможно спрогнозировать. Это может привести к непредсказуемым результатам.

Постоянная перестройка или организация очередей на обслуживание Запросов, которая соответствует принципам Automation выполняет защитные функции по исключению ситуаций Реентерабельности — пока ваш Код не вмешивается в работу Процессора. Существуют следующие варианты, когда может возникнуть ситуация перехвата управления процессором:

• Выполнение метода DoEvents.

• Запрос значений Свойств или выполнение Методов объекта из других Потоков, или даже из других Процессов. Установка значения .F. для свойства приложения Application.AutoYield = .F. приостановит процессы обработки неустойчивых Событий в интервалах между выполнением каждой строки программного Кода (VFP).

• Вызов потока типа cross-thread или обращение аналогичному (cross-process) Методу из другого метода.

Если вы тщательно не отработали исполнение вашего Объектного Кода до такого уровня, чтобы ваши методы не выполнялись в один момент времени вам не рекомендуется использовать программный код, который может перехватить управление исполняемого процессора

Многопоточная Библиотека исполнения Visual FoxPro обеспечивает Защиту характеристик и данных выполняемых Объектов от обращения к ним из других объектов Приложения. К данным объектам относятся соответствующие Глобальные объекты системы и другие подобные свойства и характеристики VFP. Некоторые системные Ресурсы представляют в этом смысле потенциальные проблемы, к ним относятся: 

• Файлы;

• Значения Ключей Реестра Windows;

• Данные.

Файлы Ввода-Вывода (I/O) представляют собой ресурсы, содержание которых может быть изменено обычными операциями самой Операционной системы. Когда ваш сервер использует некоторый Файл (или даже блокирует его) то другие процессы должны однозначно определять, что этот файл используется данным процессом (сервером). Рассматриваемый сервер должен выполнить запись в данный файл и освободить его для использования другими процессами, или достаточно Корректно обработать ошибки обращения к данному файлу. Рассматриваемые файлы Ресурсов могут быть открыты для коллективного использования, в этом случае ваш Сервер должен учитывать, что данные могут быть изменены другими процессами.

К наиболее Общему случаю относятся Файлы параметров (INI), значения переменных в которых могут читать и изменять различные процессы.Сам процесс Чтения и Записи Значения некоторого Свойства состоит из двух шагов (чтение-запись). Поэтому, существует потенциальная возможность, что в промежутке между чтением и записью значений одного процесса другой процесс выполняет аналогичную пару описанных операций. Описанный сценарий может приводить к конфликтным ситуациям..

Как и для описанных выше фалов типа INI, в разделах системного Реестра может происходить описанная выше ситуация конфликта между читаемыми и записываемыми значениями Ключей, которые обрабатываются несколькими Конкурирующими Процессами. Используемая в таких случаях подсистема Windows API обеспечивает разрешение возможных Конфликтов.

Непосредственные Данные - это достаточно гибкий и сложный Ресурс, которым совсем непросто управлять. Однако, инструментальные средства Visual FoxPro позволяют достаточно надежно и быстро выполнять обработку этого Вида Ресурсов. Дополнительную информацию вы можете просмотреть в разделе: Программирование в условиях Коллективного Доступа к Данным.

Задачи

Описание

Концепции

Другие ссылки