Многопоточность в VB

[tyomitch]

Хочется развеять ряд распространённых заблуждений.

* VB6 поддерживает многопоточные программы. В частности, на VB можно -- безо всякого шаманства -- написать многопоточный COM-сервер (как в виде ActiveX EXE, так и в виде ActiveX DLL).

Для обеспечения этого рантайм написан исключительно multithreading-aware способом: все "глобальные" данные на самом деле хранятся в TLS. Отсутствие по-настоящему глобальных данных обеспечивает защиту от race-condition-ов и других ошибок синхронизации.


* Написать на VB6 многопоточную программу намного сложнее, чем просто вызвать CreateThread(AddressOf ThreadProc), проверить под IDE (работает! вот чудо!), откомпилировать в P-Code и сделать вид, что всё в порядке.

Поскольку в этом случае межнитёвая изоляция не выполняется (глобальные объекты оказываются действительно глобальными), то в случайные и непредсказуемые моменты времени окажется, что рантайм одновременно с двух нитей читает и меняет одни и те же данные. А значит, в такой "многопоточной" программе окажется полно невылавливаемых, проявляющихся раз-на-тысячу и совершенно безпричинных багов. (См. главу книги Аппельмана про многопоточность в .net-е: он подробно описывает, как всё на самом деле сложно.)

Поскольку скомпилированная в Native Code программа расчитывает обнаружить в TLS все свои "глобальные" данные, а нить, созданная по CreateThread, не содержит TLS, то такой наивный способ запустить новую нить в скомпилированном коде не работает.


* И всё же написать на VB6 нормальную многопоточную программу возможно: для этого придётся в лучших традициях процедуры bootstrap (поднятие себя за шнурки ботинков) из созданной нити инициализировать TLS вручную. (Код на VB не может работать без TLS; как же он сам создаст себе TLS? Оказывается, сможет.)

Такие трюки, однако, требуют большого геморроя c хитрым API, который непременно нужно объявлять в TLB -- иначе магия не сработает.


* Если многопоточное VB6-приложение написано правильно, то глобальных данных -- а значит, и способов обмена данными между нитями -- нет вовсе. Координация нитей в таком приложении сопряжена с большими сложностями. (Можно, например, использовать атомы: они глобальные для оконной станции.)

Можно использовать объектные вызовы между нитями, но это именно то, чего лучше избегать: при таком вызове вызывающая нить замораживается до освобождения вызываемой -- фактически, программа превращается обратно в однопоточную. Да и откуда во вновь созданной нити взять ссылку на объект из другой нити? Ведь передать её не в чем.


* Если у вас после всего сказанного осталось желание писать на VB6 многопоточную прогу -- подумайте ещё раз. Многопоточность -- не магия, которая решит за программиста вопросы проектирования программы. Если у вас зависает однопоточная программа, то зависнет и многопоточная.

Далее, есть много способов обойтись без многопоточности. В самом худшем случае, можно запустить новую нить в крохотном ассемблерном переходнике, который будет общаться с основной программой посылкой сообщений (см. Waiter от GSerg-а). Но часто удаётся решить проблему одновременного выполнения нескольких задач вовсе не выходя за рамки одной нити (см. мои посты про фиберы).

[Twister]

Нашел в сети статейку Appleman-а, может кому будет интересно почитать...

[tyomitch]

Twister, ты осознаёшь, что эта статья -- про VB5, и далеко не целиком применима к VB6?

[Twister]

Сознаю. Но думаю кое-что полезное почерпнуть из нее можно...

[ANDLL]

Поскольку скомпилированная в Native Code программа расчитывает обнаружить в TLS все свои "глобальные" данные, а нить, созданная по CreateThread, не содержит TLS, то такой наивный способ запустить новую нить в скомпилированном коде не работает.

Я не могу понять, на основе чего создалось мнение, что обычная EXE-программа на VB хранит глобальные переменные в TLS?

[tyomitch]

На основе заглядывания внутрь.
Хочешь -- перепроверь.

[ANDLL]

Тогда можно попорядку и "для чайников", как такое заглядывание внутрь можно организовать? Вот, скажем, в этом проекте идет обращение к глобальной переменной A... Но где там что-то касающееся TLS?
http://danasoft.ru/users/andll/for_tyomitch.zip
Чего не прикрепляются вложения? Права недонастроили?

[tyomitch]

Про права -- это к RayShade.
Про глобальные переменные -- поставь в своём любимом отладчике брякпойнт на TlsSetValue, и посмотри, сколько раз она вызовется. У меня вызвалась 22 раза.

[ANDLL]

и? Из того что он где-то вызывается еще не следует, что глоабальные переменные хранться в TLS, разве нет?
Поставь брейкпоинт на A=5 (проект компилировался с Debug symbols).
И ты увидиш, что в компиляции этой команды нету обрашения к системным функциям вообще.

[tyomitch]

[edit]софистика оказалась излишней[/edit]

[ANDLL]

Хорошо. Что, по-твоему, хранится в TLS? очевидно, какие-то переменные.
В однопоточной проге они глобальные. Значит, в TLS хранятся глобальные переменные

Я полагает, нелишне напомнить, что мир устроен так как он устроен, а не так как он ДОЛЖЕН быть устроен.

[tyomitch]

Хорошо. Что, по-твоему, хранится в TLS?

[tyomitch]

Проверил детально. Публичные переменные модулей лежат не в TLS.

Однако, все стандартные функции рантайма (за небольшим исключением) пользуются TLS. В частности, им пользуется механизм обработки исключений, так что любая команда, потенциально способная вызвать исключение, неявно использует TLS.

Т.е. по сути я всё же прав: без TLS ничего не заработает.


--------------------
Кстати:

Поскольку скомпилированная в Native Code программа расчитывает обнаружить в TLS все свои "глобальные" данные, а нить, созданная по CreateThread, не содержит TLS, то такой наивный способ запустить новую нить в скомпилированном коде не работает.

Я не могу понять, на основе чего создалось мнение, что обычная EXE-программа на VB хранит глобальные переменные в TLS?

Я не могу понять, на основе чего создалось мнение, что "глобальные данные" программы -- это именно публичные переменные её модулей?

[ANDLL]

А что, публичные переменные не являются глобальными данными?

[tyomitch]

А что, глобальные данные исчерпываются публичными переменными?

[ANDLL]

Не исчерпываются:)

все "глобальные" данные на самом деле хранятся в TLS

Однако же все как раз там и не храняться...
Я имел ввиду это.