Потоки в Visual Basic
С появлением оператора AddressOf, часть индустрии ПО стала ориентироваться на авторов, показывающих как с использованием Visual Basic решать ранее невозможные задачи. Другая часть быстро охватила консультантов, помогающих пользователям, имеющим проблемы при решении таких задач.
Проблема не в Visual Basic или в технологии. Проблема в том, что большинство авторов применяют одно и тоже правило к AddressOf методикам, что большинство компаний по разработке ПО считают, что если Вы должны что-то сделать, то Вы сможете. Идея о том, что применение самой новой и последней технологии должно, по определению, быть самым лучшим решением проблемы, широко распространена в индустрии ПО. Эта идея неверна. Развертывание технологии должно управляться прежде всего проблемой, которую необходимо решить решить, а не технологией, которую кто-то пробует Вам впарить;).
Очень плохо, что из-за того, что компании часто пренебрегают упоминанием об ограничениях и недостатках их инструментальных средств, авторы иногда бывают не в состоянии обратить внимание читателей на следствия некоторых методик, которые они описывают. И журналы и книги иногда пренебрегают своей ответственностью, чтобы удостовериться, что практика программирования, которую они описывают, является приемлемой.
Программисту очень важно выбрать необходимый инструмент для своей работы. Это - ваша задача, чтобы разработать код, который работает теперь не только на одной специфической платформе, но также работает на разных платформах и системных конфигурациях. Ваш код должен быть хорошо документирован и поддержан другими программистами, участвующими в проекте. Ваш код должен следовать правилам, продиктованными операционной системой или стандартами, которые Вы используете. Отказ так делать может привести к проблемам в будущем, поскольку системы и программное обеспечение постоянно совершенствуются.
|
|
Недавние статьи в Microsoft Systems Journal и Visual Basic Programmer's Journal представили программистам на Visual Basic возможность использования функции API CreateThread, чтобы непосредственно поддерживать многопоточный режим под Visual Basic. После этого, один читатель пожаловался, что моя книга Visual Basic Programmer's Guide to the Win32 API является неполной, потому что я не описал в ней эту функцию и не продемонстрировал эту технологию. Эта статья - частично является ответом этому читателю, и частично - ответом на другие статьи, написанными на эту тему. Эта статья также является дополнением к главе 14 моей книги "Разработка ActiveX компонент на Visual Basic 5.0" относительно новых возможностей, обеспечиваемых Visual Basic 5.0 Service Pack 2.
Быстрый обзор Многопоточности
Если Вы уже хорошо разбираетесь в технологии многопоточного режима, то Вы можете пропустить этот раздел и продолжать чтение с раздела, названного "Что нового в Service Pack 2."
Каждый, кто использует Windows, знает, что Windows способно делать больше чем одну вещь одновременно. Может одновременно выполнять несколько программ, при одновременном проигрывании компакт-диска, посылке факса и пересылке файлов. Каждый программист знает (или должен знать) что ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР компьютера может только выполнять одну команду одновременно (проигнорируем существование многопроцессорных машин). Как единственный ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР может выполнять множество задач?
|
|
Это делается быстрым переключением между многими задачами. Операционная система содержит в памяти все программы, которые запущены в настоящий момент. Это позволяет ЦЕНТРАЛЬНОМУ ПРОЦЕССОРУ выполнять программы по очереди. Каждый раз происходит переключение между программами, при этом меняется содержимое внутренних регистров, включая указатель команды и указатель вершины стека. Каждая из таких "задач" называется потоком выполнения (thread of execution).
В простой многозадачной системе, каждая программа имеет емеет единственный поток. Это означает, что ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР начинает выполнение команд в начале программы и продолжает следуя инструкциям в последовательности, определенной программой до тех пор, пока программа не завершается.
Скажем, программа имеет пять команд: B C D и E, которые выполняются последовательно (никаких переходов нет в этом примере). Когда приложение имеет один поток, команды будут всегда выполнять в точно том же самом порядке: A, B, C, D и E. Действительно, ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР может потребовать времени для выполнения других команд в других программах, но они не будут влиять на это приложение, если не имеется конфликт над общими ресурсами системы, но это уже отдельная тема для разговора.
Продвинутая многопоточная операционная система типа Windows позволяет приложению выполнять больше чем один поток одновременно. Скажем, команда D в нашем типовом приложении могла создать новый поток, который стартовал командой B и далее выполнял последовательность команд C и E. Первый поток был бы все еще A, B, C, D, E, но когда команда D выполнится, возникнет новый поток, который выполнит команды бы B, C, E (здесь команды D уже не будет, иначе мы получим еще один поток).
В каком порядке будут следовать команды в этом приложении?
Это могло бы быть:
Thread 1 A B C D E
Thread 2 B C E
Или так:
Thread 1 A B C D E
Thread 2 B C E
Или этак:
Thread 1 A B C D E
Thread 2 B C E
Другими словами, когда Вы начинаете новый поток выполнения в приложении, Вы никогда не можете знать точный порядок, в котором команды в двух потоках выполнятся относительно друг друга. Два потока полностью независимы.
Почему - это проблема?