74954-1 (Потоки в Visual Basic), страница 4
Описание файла
Документ из архива "Потоки в Visual Basic", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "рефераты, доклады и презентации", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "74954-1"
Текст 4 страницы из документа "74954-1"
Что, если Вы хотите выполнить фоновую операцию, которая не должна использовать объект? Очевидно, проблемы с соглашением COM о потоках исчезают. Но появляются другие проблемы. Как фоновый поток сообщит о своем завершении приоритетному потоку? Как они обмениваются данными? Как два потока будут синхронизированы? Все это возможно выполнить с помощью соответствующих вызовов API. В моей книге Visual Basic 5.0 Programmer's Guide to the Win32 API имеется информации относительно объектов синхронизации типа Событий, Mutexes, Семафоров и Waitable Таймеров.
Эта книга также включает примеры файлов отображаемых в память, которые могут быть полезны при обмене данных между процессами. Вы сможете использовать глобальные переменные, чтобы обмениваться данные, но надо знать, что такое поведение не гарантируется Visual Basic(другими словами, даже если это сейчас работает, не имеется никаких гарантий, что это будет работать в будущем). В этом случае я мог бы предложить Вам использовать для обмена данными методики, основанные на API. Однако, преимуществом показанного здесь подхода, основанного на объектах, является то, что этот подход делает проблему обмена данными между потоками тривиальной, просто делайте это через объект.
Заключение
Я однажды услышал от опытного программиста под Windows, что OLE является самой трудной технологией, которой он когда-либо обучался. Я с этим согласен. Это очень обширная тема, и некоторые части этой технологии очень трудно понять. Visual Basic, как всегда, скрывает от Вас много сложностей.
Имеется сильное искушение, чтобы пользоваться преимуществом продвинутых методов типа многопоточного режима, используя подход "tips and techniques". Это искушение поощрено некоторыми статьями, которые иногда представляют специфическое решение, приглашая Вас вырезать и вставить (cut and past) их методики в ваши собственные приложения.
Когда я писал книгу Visual Basic Programmer's Guide to the Windows API, я выступал против такого подхода к программированию. Я чувствовал, что вообще безответственно включать в приложение код, который Вы не понимаете, и что реальное знание, которое так тяжело получить, стоит затраченных усилий.
Таким образом мои книги по API были разработаны, чтобы обеспечить не быстрые ответы и простые решения, а чтобы обучить использованию API к такой степени, что программисты могли бы интеллектуально правильно применять даже наиболее продвинутые методы. Я применил это тот же самый подход к моей книге Developing ActiveX Components, которая требует много времени для обсуждения принципов ActiveX, COM и объектно-ориентированного программирования перед описанием подробностей реализации этой технологии.
Многое из моей карьеры на ниве Visual Basic и многое из деятельности в фирме Desaware, основано на обучении Visual Basic программистов продвинутым методам. Читатель, кто вдохновил меня на написание этой статьи, критикуя меня за сдерживание технологии многопоточности, пропустил точку.
Да, я обучаю и демонстрирую продвинутые методы программирования - но я пытаюсь никогда не пропустить большую картинку. Продвинутые методы, которым я обучаю, должны быть непротиворечивы с правилами и спецификациями Windows. Они должны быть такими безопасными, насколько это возможно.
Они должны быть поддерживаемыми в конечном счете. Они не должны разрушаться, когда изменяются Windows или Visual Basic.
Я могу требовать только частичного успеха, так как Microsoft может изменить правила игры всякий раз, когда им покажется, что это необходимо. Но я всегда помню об этом и пробую предупреждать людей, когда я думаю, что могу протолкнуть ограничение.
Я надеюсь, что приведенное здесь обсуждение многопоточного режима показывает опасности применения "простых методов" без хорошего понимания основной технологии.
Я не могу обещать, что использование apartment model версии CreateThread является абсолютно корректным, но мое понимание проблемы и опыт показывают, что это безопасно.
Могут иметься другие факторы, которые я пропустил. OLE - действительно сложная вещь и модули OLE DLL и сам Visual Basic подвержены изменениям. Я только могу утверждать, что лучшее из моего знания - код, который я здесь показал, удовлетворяет правилам COM и что эмпирическое доказательство показывает, что Visual Basic runtime 5 0's является достаточно безопасным для выполнения фонового кода потока в стандартном модуле.
Список литературы
Для подготовки данной работы были использованы материалы с сайта http://visualprogs.narod.ru/