Первоначальный выпуск Visual Basic 5.0 позволял использовать многопоточность только в компонентах, которые не имели никаких элементов пользовательского интерфейса. Так было потому что они не имели безопасного потока управления формами. Например: когда Вы создаете форму в Visual Basic, VB дает ей имя глобальной переменной (таким образом, если Вы имеете форму, именованную Form1, Вы можете непосредственно обращаться к ее методам, используя Form1.метод вместо того, чтобы объявить отдельную переменную формы). Этот тип глобальной переменной может вызывать проблемы многопоточного режима, которые Вы видели ранее. Имелись несомненно другие проблемы внутри управления формами.
С service pack 2, управление формами Visual Basic было сделано безопасным потоком. Это говорит о том, что каждый поток имеет собственную глобальную переменную для каждой формы, определенной в проекте.
Что нового в Service Pack 2
Сделав поток управления формами безопасным, Service pack 2 предоставил возможность с помощью Visual Basic создавать клиентские приложения, использующие многопоточный режим.
Приложение должно быть определено как программа ActiveX Exe с установкой запуска из Sub Main:
' MTDemo2 - Multithreading demo program
' Copyright © 1997 by Desaware Inc. All Rights Reserved
Option Explicit
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Sub Main()
Dim f As frmMTDemo2
' We need this because Main is called on each new thread
Dim hwnd As Long
hwnd = FindWindow(vbNullString, "Multithreading Demo2")
If hwnd = 0 Then
Set f = New frmMTDemo2
f.Show
Set f = Nothing
End If
End Sub
Первый раз программа загружает и отображает основную форму приложения. Подпрограмма Main должна выяснить, является ли это первым потоком приложения, поэтому этот код выполняется при старте каждого потока. Вы не можете использовать глобальную переменную, чтобы это выяснить, потому что Visual Basic apartment model хранит глобальные переменные специфическими для одиночного потока. В этом примере используется функция API FindWindow, чтобы проверить, была ли загружена основная форма примера. Имеются другие способы выяснить, является ли это основным потоком, включая использование объектов синхронизации системы - но это отдельная тема для разговора.
Многопоточный режим реализуется созданием объекта в новом потоке. Объект должен быть определен, используя модуль класса. В этом случае, простой модуль класса определяется следующим образом:
' MTDemo2 - Multithreading demo program
' Copyright © 1997 by Desaware Inc. All Rights Reserved
Option Explicit
Private Sub Class_Initialize()
Dim f As New frmMTDemo2
f.Show
Set f = Nothing
EndSub
Мы можем установить переменную формы как nothing после того, как она создана, потому что после отображения формы она будет сохранена.
' MTDemo2 - Multithreading demo program
' Copyright © 1997 by Desaware Inc. All Rights Reserved
Option Explicit
Private Sub cmdLaunch1_Click()
Dim c As New clsMTDemo2
c.DisplayObjPtr Nothing
End Sub
Private Sub cmdLaunch2_Click()
Dim c As clsMTDemo2
Set c = CreateObject("MTDemo2.clsMTDemo2")
End Sub
Private Sub Form_Load()
lblThread.Caption = Str$(App.ThreadID)
EndSub
Форма отображает идентификатор потока в метке на форме. Форма содержит две командные кнопки, одна из которых использует оператор New, другая -использует оператор CreateObject.
Если Вы запустите программу внутри среды Visual Basic, то увидите, что формы всегда создаются в одном и том же потоке. Это происходит, потому что среда Visual Basic поддерживает только одиночный поток. Если Вы скомпилируете и запустите программу, то увидите, что подход, использующий CreateObject создает и clsMTDemo2 и ее форму в новом потоке.
Почему многопоточность
Откуда вся суета относительно многопоточного режима, если он включает так много потенциальной опасности? Потому что, в некоторых ситуациях, многопоточный режим может значительно улучшать эффективность приложения. В некоторых случаях это может улучшать эффективность некоторых операций синхронизации типа ожидания завершения приложения. Это позволяет сделать архитектуру приложения более гибкой. Например, операция Add a long в форме MTDEMO2 со следующим кодом:
Private Sub cmdLongOp_Click()
Dim l&
Dim s$
For l = 1 To 1000000
s = Chr$(l And &H7F)
Next l
End Sub
Запустите несколько экземпляров формы, используя кнопку cmdLaunch1. Когда Вы нажимаете на кнопку cmdLongOp на любой из форм, то увидите, что это действие замораживает операции на всех других формах. Так происходит, потому что все формы выполняются в одиночном потоке - и этот поток занят выполнением длинного цикла. Если Вы запустите несколько экземпляров формы кнопкой cmdLaunch2 и нажимете кнопку cmdLongOp на форму, то только эта форма будет заморожена - другие формы будут активными. Они выполняются в собственных потоках, и длинный цикл будет выполняться только в собственном потоке. Конечно, в любом случае, Вы вероятно не должны размещать длительные операции такого типа в ваших формах.
Дальше краткое резюме, когда важен многопоточный режим:
Сервер ActiveX EXE – без общих ресурсов.
Когда Вы имеете ActiveX EXE сервер, который Вы собираетесь совместно использовать среди нескольких приложений, многопоточный режим предотвращает приложения от нежелательных взаимодействий с друг другом. Если одно приложение выполняет длинную операцию на объекте в однопоточном сервере, другие приложения будут вытеснены, т.е. будут ждать, когда освободится сервер. Многопоточный режим рещает эту проблему. Однако, имеются случаи, где Вы можете хотеть использовать ActiveX EXE сервер, чтобы регулировать доступ к общедоступнному ресурсу (shared resource). Например, сервер stock quote, описанный в моей книге Developing ActiveX Components. В этом случае сервер stock quote выполняется в одиночном потоке и который доступен для всех приложений, использующих сервер по очереди.
Многопоточный клиент – выполняемый как ActiveX EXE сервер
Простая форма этого подхода продемонстрирована в приложении MTDEMO2. Этот подход используется, когда приложение поддерживает множественные окна, которые должны исходить из одного приложения, но работать полностью независимо. Интернет-браузер - хороший пример такого многопоточного клиента, где каждое окно выполняется в собственном потоке. Здесь следует обратить внимание на то, что многопоточный режим не должен использоваться как замена для хорошего событийно управляемого проекта.
Многопоточные серверы DLL или EXE
В архитектуре клиент-сервер, многопоточный режим может увеличить эффективность, если Вы имеете смесь длинных и коротких клиентских запросов. Будьте внимательным, хотя - если все ваши клиентские запросы имеют подобную длину, многопоточный режим может фактически замедлять среднее время ответа сервера! Никогда не принимайте на веру тот факт, что если ваш сервер является многопоточным, то обязательно его эффективность увеличится.
Соглашение о потоках
Верите или нет, но все это было введением. Часть этого материала является обзором материала, который описан в моей книге Developing ActiveX Components, другая часть материала описывает новую информацию для service pack 2.
Теперь, позволите задавать вопрос, который имеет отношение к многопоточному режиму, использующему COM (модель многокомпонентных объектов, на которой основаны не только все Visual Basic объекты, но и другие windows приложения, использующие технологии OLE).
Дано:
Многопоточный режим является потенциально опасным вообще, и особенно попытки многопоточного кодирования приложений, которые не разработаны для поддержки многопоточного режима, скорее всего приведут к фатальным ошибкам и сбоям системы.
Вопрос:
Как это возможно, что Visual Basic позволяет Вам создавать объекты и использовать их с одиночными и многопоточными средами безотносительно к тому, разработаны ли они для одиночного или многопоточного использования?
Другими словами - Как многопоточные Visual Basic приложения могут использовать объекты, которые не разработаны для безопасного выполнения в многопоточной среде? Как могут другие многопоточные приложения использовать однопоточные объекты Visual Basic?
Коротко: как COM поддерживает потоки?
Если Вы знаете COM, то Вы знаете, что COM определяет структуру соглашения. Объект COM соглашается следовать некоторым правилам так, чтобы этим можно было успешно пользоваться из любого приложения или объекта, который поддерживает COM.
Большинство людей сначала думает о интерфейсной части соглашения - о методах и свойствах, которые предоставляет объект.
Но Вы не можете не знать того, что COM также определяет поточность как часть соглашения. И подобно любой части соглашения COM - если Вы нарушаете эти условия, то будете иметь проблемы. Visual Basic, естественно, скрывает от Вас большинство механизмов COM, но чтобы понять как использовать многопоточность в Visual Basic, Вы должны разобраться COM модели потоков.
Модель одиночного потока:
Однопоточный сервер - самый простой тип реализации сервера. И самый простой для понимания. В этом случае EXE сервер выполняется в одиночном потоке. Все объекты создаются в этом потоке. Все вызовы методов каждого объекта, поддерживаемого сервером должны прибыть в этот поток.
Но что будет, если клиент выполняется в другом потоке? В том случае, для объекта сервера должен быть создан промежуточный объект (proxy object). Этот промежуточный объект выполняется в потоке клиента и отражает методы и свойства фактического объекта. Когда вызывается метод промежуточного объекта, он выполняет операции, необходимые для подключению к потоку объекта, а затем вызывает метод фактического объекта, используя параметры, переданные к промежуточному объекту. Естественно, что этот подход требует значительного времени на выполнение задачи, однако он позволяет выполнить все соглашения. Этот процесс переключения потоков и пересылки данных от промежуточного объекта к фактическому объекту и обратно называется marshalling. Эта тема обсуждается в главе 6 моей книги Developing ActiveX Components.
В случае DLL серверов, одиночная потоковая модель требует, чтобы все объекты в сервере создавались и вызывались в том же самом потоке что и первый объект, созданный сервером.
Модель Apartment Threading
Обратите внимание, что модель Apartment Threading как определено COM не требует, чтобы каждый поток имел собственный набор глобальных переменных. Visual Basic таким образом реализует модель Apartment Threading. Модель Apartment Threading декларирует, что каждый объект может быть создан в собственном потоке, однако, как только объект создан, его методы и свойства могут вызываться только тем же самым потоком, которая создал объект. Если объект другого потока захочет иметь доступ к методам этого объекта, то он должен действовать через промежуточный объект.