PowerBASIC vs PureBasic

[Trink]

Вот еще пример многопоточности, каждое окно создается в своем потоке.

Только вот окна создаются непосредственно Win api функциями и использованы методы синхронизации, а выше писали что при этом большая вероятность "выстрелить в ногу". То есть вот какая она простота VB? Код прог показывает обратное.
Чисто средствами VB (его формами) такое не сделать?

На PureBasic подобное реализуется библиотечными функциями (без прямой работы с Win api) и не нужны методы синхронизации потоков, т. к. библиотечные функции PureBasic потокобезопасные и необходимые меры предотвращения коллизии потоков, уже предприняты.
Код получается намного проще и понятнее.

Код: Выделить всё

CompilerIf #PB_Compiler_Thread=0
  CompilerError "Включите поддержку многопоточности в настройках компилятора"
CompilerEndIf

Procedure NewWin(Num)
 
  WinID = OpenWindow(#PB_Any, 100+Random(300), 100+Random(300), 400, 400, "Окно №"+Str(Num), #PB_Window_MinimizeGadget)
  ButtonID = ButtonGadget(#PB_Any, 150, 175, 100, 50, "Sleep(10000)")
 
  Repeat
    Event = WaitWindowEvent()
   
    If Event = #PB_Event_Gadget
      If EventGadget()=ButtonID
        Delay(1000)
      EndIf
    EndIf
   
  Until Event = #PB_Event_CloseWindow
 
  CloseWindow(WinID)

EndProcedure

OpenWindow(0, 0, 0, 300, 200, "Многопоточная прога", #PB_Window_MinimizeGadget|#PB_Window_ScreenCentered)
StickyWindow(0, #True)
ButtonGadget(0, 100, 75, 100, 50, "Новое окно")

Repeat
  Event = WaitWindowEvent()
 
  If Event = #PB_Event_Gadget
    If EventGadget()=0
      CreateThread(@NewWin(), Count) : Count+1
    EndIf
  EndIf
 
Until Event = #PB_Event_CloseWindow

И исполняемый файл на PureBasic получился меньше в размере чем на VB, хотя в VB рантайм отдельно, а PureBasic, рантайм линкует статически к исполняемому файлу.

Так что VB полностью проигрывает.

[Хакер]

и не нужны методы синхронизации потоков, т. к. библиотечные функции PureBasic потокобезопасные

Trink. Ты несёшь чушь. Ты понимаешь это?

[Trink]

Почему чушь?
Исходники смотрел? В VB коде использован мьютекс. В коде PureBasic как видишь нет мьютекса. Но он есть в библиотечных функциях.

[Хакер]

Потому что:

• В твоей голове живёт ошибочная картина мира, в которой функции синхронизации потоков существуют во имя обезопасивания работы библиотеки функций. И нужны, видимо, только тогда, когда приходится работать с непотокобезопасным рантаймом.
  В то время как на самом деле нужны они для избежания ошибок синхронизации. А могут ли возникнуть ошибки синхронизации или нет, зависит от архитектуры, от кода, от алгоритмов в приложении.
  
  Если создатели рантайма посчитали, что в коде самого рантайма ошибки синхронизации возникнуть могут, значит они должны в коде рантайма использовать методы межпоточной синхронизации. Но из того факта, что они их там использовали, АБСОЛЮТНО НЕ СЛЕДУЕТ, что в коде прикладной программы теперь можно забыть о них.
  
  
• В твоей голове существует убеждение, что рантайм VB6 — непотокобезопасен. Это адская ложь. Там каждый чих окружён использованием синхронизационных примитивов. Код рантайма это какой-то эталон заботы о межпоточной синхронизации. Если строить список вещей, где этой синхронизации не хватает, то рантайм VB обязан оказаться на последнем месте рейтинга.

[The trick]

использованы методы синхронизации, а выше писали что при этом большая вероятность "выстрелить в ногу". То есть вот какая она простота VB?

Писать многопоточную прогу без использования синхронизации доступа к общим данным - неправильно. Понимаешь, я бы мог не использовать мьютекс, и все будет работать нормально (в данном примере), но я его поставил потому что так надо (если ты захочешь вызвать NewWindow из другого потока в цикле)

Чисто средствами VB (его формами) такое не сделать?

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

На PureBasic подобное реализуется библиотечными функциями (без прямой работы с Win api) и не нужны методы синхронизации потоков, т. к. библиотечные функции PureBasic потокобезопасные и необходимые меры предотвращения коллизии потоков, уже предприняты.

Если ты читал посты, которые тебе показывали, то ты бы знал что у VB рантайм тоже потокобезопасный это и доказывает пример с ActiveX EXE. Не так ли?

И исполняемый файл на PureBasic получился меньше в размере чем на VB, хотя в VB рантайм отдельно, а PureBasic, рантайм линкует статически к исполняемому файлу. Так что VB полностью проигрывает.

- Это непринципиально, или ты что собрался прошивать этой прогой МК? Ты просил показать тебе многопоточность в EXE проекте, тебе показали 2 примера.

[Trink]

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

Ошибаетесь. У меня есть опыт разработки многопоточных приложений и прекрасно знаю для чего нужны мьютексы/критические секции и семафоры.

Но из того факта, что они их там использовали, АБСОЛЮТНО НЕ СЛЕДУЕТ, что в коде прикладной программы теперь можно забыть о них.

Согласен. Но в коде выше на PureBaasic, не требуются отдельные методы синхронизации. Достаточно тех что реализованы в библиотечных функциях.

В твоей голове существует убеждение, что рантайм VB6 — непотокобезопасен.

Где я такое написал? Я лишь написал что в потоках в место форм VB, создаются окна непосредственным вызовом winapi. Почему? Предполагаю что формы не такие уж и многопоточные.

Там каждый чих окружён использованием синхронизационных примитивов.

Зачем это нужно если почти во всех VB прогах только один поток? Синхронизация будет тратить ресурсы в пустую. Например в PureBasic, программист решает использовать потокобезопасные библиотеки или нет.

Писать многопоточную прогу без использования синхронизации доступа к общим данным - неправильно. Понимаешь, я бы мог не использовать мьютекс, и все будет работать нормально (в данном примере), но я его поставил потому что так надо (если ты захочешь вызвать NewWindow из другого потока в цикле)

Я то это понимаю.
Но и вы поймите, при активации многопоточности в настройках компилятора PureBasiс, используется потокобезопасный код и можно хоть по 20 окон в цикле создавать

Код: Выделить всё

      For i=1 To 20
        CreateThread(@NewWin(), Count) : Count+1
      Next i

Отдельные меры для синхронизации не нужны. Она обеспечивается средствами компилятора и библиотек.

[The trick]

Отдельные меры для синхронизации не нужны. Она обеспечивается средствами компилятора и библиотек.

Ну так и в том примере, в котором используется ActiveX EXE можно в цикле сделать и никакие средства синхронизации не нужны.

Зачем это нужно если почти во всех VB прогах только один поток?

Не всегда один, пример с ActiveX EXE это подтверждает.

[iGrok]

Только вот окна создаются непосредственно Win api функциями и использованы методы синхронизации, а выше писали что при этом большая вероятность "выстрелить в ногу"

Где это выше ТАКОЕ написано?! Зачем продолжать притягивать за уши аргументы, совершенно не глядя на то, что именно ими было аргументировано?

Я лишь написал что в потоках в место форм VB, создаются окна непосредственным вызовом winapi. Почему?

Потому что при создании потока нужно сначала инициализировать рантайм. Без этого любое обращение к рантайму выдаст исключение.
В случае создания потока в activex-сервере инициализация проводится "автоматически" (точнее, насколько я понимаю, средствами самого рантайма).
В случае "ручного" создания потока этого не происходит (потому что ручное создание потоков вообще не планировалось), тут-то и нужен "кирпич" Хакера.

[Хакер]

Я лишь написал что в потоках в место форм VB, создаются окна непосредственным вызовом winapi. Почему? Предполагаю что формы не такие уж и многопоточные.

Потому что речь идёт о примере с каким-то трюкачеством. Трюкачества обсуждать не хочется, хотя это одна из моих любимых тем.

Зачем это нужно если почти во всех VB прогах только один поток?

Затем, что поток может быть не один. Никто не запрещает иметь их много.

Но во-первых, нужно зарубить себе на носу, что если ты пишешь на VB, то нельзя (или по крайней мере — чревато) пользоваться функций CreateThread. Это не какой-то уникальный случай. Такая же история с Си.

Если ты пишешь многопоточную программу на Си под Windows, и пользуешься сишным рантаймом, то ты тоже не имеешь права вызывать CreateThread. Вместо этого ты должен вызывать _beginthread или _beginthreadex. Только так сишный рантайм имеет шанс самоинициализироваться для нового потока.

Тебя не смущает это? Тебя не возмущает, то что Си устроен и живёт по таким правилам.

Эти правила достаточно обоснованы. И в VB ситуация аналогичная. Нельзя просто создавать поток, используя CreateThread, передавая управление на свой код, не позаботившись перед этим об инициализации рантайма.

Окей.

Есть ли аналог сишного _beginthread или _beginthreadex в VB-райнтайме? Ну, во-первых, VB-рантайм написан на Си/Си++, поэтому сишный рантайм вшит в него (статически влинкован). Поэтому внутри VB-рантайма тоже живёт функция _beginthreadex. Обращение к ней идёт из CVBThreadAction::InitExeThrd. А к ней идёт обращение из CThreadPool::_InitThread.

Напрямую вызвать что-нибудь из этого для создания нового потока — такую возможность создатели VB сознательно исключили наравне с возможность выделять память вручную.

Тем не менее, можно порождать объекты, для которых будут порождаться новые потоки. Таким образом, создав VB-класс CWorkerThread, можно получать со своей стороны (со стороны главного потока) объект, олицетворяющий другой поток. Имея у этого класса методы типа PutJobIntoQueue, можно из главного потока посылать какую-то работу в очередь другого потока. И тот будет делать. Тот будет делать, а потом дёргать у этого класса CWorkerThread событие JobCompletion, для того, чтобы уведомлять главный поток о том, что работа закончилась (и сообщать какой-то результат).

Единственное недоразумение: режим, при котором под каждый новый объект создаётся новый поток — возможен только при типе проекта, равном ActiveX EXE. В стандартном проекте дропдаун «Threading Model» в свойствах проекта залочен. Недоразумение. Жалко. Не не катастрофа. Проект типа ActiveX EXE ничем не хуже проекта типа Standard EXE.

У меня таким образом написан многопоточный сервер на VB, задействованный в одном крупном проекте. Я написал его за две недели как быстрый черновик, чтобы найти проблемы в архитектуре и через некоторое время переписать этот же сервер в виде сервиса на сях. Но проблем не нашлось, а сервер на VB всем понравилось, поэтому люди, которые финансируют разработку, даже отказались финансировать переписывание сервера с VB на Си. Так и работает этот сервер уже больше года, обрабатывая 300 тысяч запросов в сутки. Стабильно и гладко. Мы уже забыли о нём и воспринимаем его безупречную работу как что-то само собой разумеющееся и незыблемое.

_____________

Кроме того, значительную долю пирога применения VB составляет написание DLL-библиотек и OCX-контролов. Поэтому твой вопрос

Зачем это нужно если почти во всех VB прогах только один поток?

тут звучит глупо.

Затем, что на VB ты можешь писать классы и юзер-контролы, которые будут успешно работать в рамках других многопоточных приложений. Чужих. Сишных. Дейльфишных. VB-шных. Каких угодно.

Очень классно и удобно писать на VB экстеншоны для IE или проводника (файлового). Причём даже для новых IE они пишутся до сих пор так же, как для 5–6-го. Проводник и IE — многопоточные приложения, но потокобезопасный рантайм обеспечивает контролам и просто DLL-шным классам нормальную работу.

Так поддерживает ли VB многопоточность? Единственное, чего не поддерживает VB: это создания потока напрямую, насильно, без создания объекта. Но для этого я делал кирпич. Там вот процентов 10 доделать, и тогда VB будет и это поддерживать.

[Trink]

Где это выше ТАКОЕ написано?!

Вот не поверишь. В исходнике написано. Изучай. viewtopic.php?f=49&t=39210&start=210#p6771744

Зачем продолжать притягивать за уши аргументы, совершенно не глядя на то, что именно ими было аргументировано?

Это ты не смотришь исходники и сходу пишешь. Смотри ссылку выше.

Потому что при создании потока нужно сначала инициализировать рантайм. Без этого любое обращение к рантайму выдаст исключение.

Вот этим все сказано. Я изначально писал что VB из коробки не поддерживает многопоточность в стандартных EXE.

[iGrok]

В исходнике написано.

Там и отдалённо нет ничего подобного.

Ещё раз:

Только вот окна создаются непосредственно Win api функциями и использованы методы синхронизации, а выше писали что при этом большая вероятность "выстрелить в ногу".

Где "выше" ТАКОЕ написано?

Я изначально писал что VB из коробки не поддерживает многопоточность в стандартных EXE.

Ничего подобного. Утверждалось совсем другое.
Да и опять же, VB - очень даже поддерживает. Просто совсем не так, как ты привык.
Вот если ещё и объяснишь, что ты понимаешь под "стандартными EXE", и чем они, по-твоему, лучше activex, что тут вокруг них такие баталии развернулись, тогда можно будет продолжить.

Да, один момент. Не надо строить аргументацию на названии типа проекта "Standard EXE". Это будет большой глупостью.

[strange2007]

Плюсы пурика перед другими (не всеми) средами для разработки (личный опыт и не более):
Свобода выбора стиля без каких либо ограничений. Т.е. можно и не знать win api и ограничиваться функционалом пурика, а можно воспользоваться маниакальными способностями и лабать в машинных кодах. Т.е. фанаты асма или использующие его по необходимости могут соревноваться в флэшкомерянии кто лучше знает тонны информации. а при необходимости можно и работу делать выдавая результаты без подобных сложностей.

Небольшой курс по решению задач (личный опыт + опыт мировых производителей):
Различные уровни абстракции создания решений придуманы как раз для создания решений)))) Скажем так, на 1С-ке либо Парусе на несколько порядков быстрее и качественнее создаются решения для крупнейших предприятий во многих сферах (например, автоматизация крупного энерго холдинга) тогда как на ассемблере это невозможно в принципе. Это к тому. что под каждую задачу вместо фанатизма надо выбирать свою среду.

И последнее - плохом танцору всё что угодно мешает, поэтому, автор, оценивай рынок заказов, а не крутизну синтаксиса. Привыкнуть к слэшу в качестве доступа к полям структуры можно за несколько минут и это не проблема, а вот закопаться в задаче на 5 лет, тогда как другие её делают. например, на 1С за пару месяцев, это уже миллионы денег, репутация и проблемы на предприятиях страны. Деньги платят не за красивый код, а только за результат.

P.S. По работам использую 1С, а для души использую только пурик + fasm