многопоточность это хорошо, если она нужна. Если не HFT, то необходимость многопоточности под большим вопросом. Хотя если код парсит/качает данные с каких-нибудь сайтов, то тогда можно об этом подумать. В общем, если нужна многопоточность, то ты это поймешь, когда запустишь код на одном потоке и он будет подвисать.
Да, лично я использую и в не HFT тоже. Но это связано лишь с тем, что использую C# в своих работах. И по многопоточности, тут вопрос скорее к языку реализации робота, ну и ещё конечно к компетенции программиста, если язык поддерживает многопоточность.
Если это C#, С++, Delphi, и т.д. то значит, приходится в любом случае соединяться с каким-то источником данных (Api, терминал или файл) и создавать свой интерфейс. Данные идущие из любого терминала, при событийной архитектуре, создают новые потоки (Quik DDE, SmartCom). Если данные парсятся, то также это делается отдельными классами (и циклами, и потоками соответственно). Обработка интерфейса требует также отдельных потоков, чтобы не тормозить модель. И вообще много где можно многопоточность использовать (лично я, этим злоупотребляю).
Если в роботе использованы какие-то из языков, встроенных в терминал, то, скорее всего многопоточности нет. Но лишь по тому, что в подобных языках существует на это дело ограничение.
Если это C#, С++, Delphi, и т.д. то значит, приходится в любом случае соединяться с каким-то источником данных (Api, терминал или файл) и создавать свой интерфейс. Данные идущие из любого терминала, при событийной архитектуре, создают новые потоки (Quik DDE, SmartCom). Если данные парсятся, то также это делается отдельными классами (и циклами, и потоками соответственно). Обработка интерфейса требует также отдельных потоков, чтобы не тормозить модель. И вообще много где можно многопоточность использовать (лично я, этим злоупотребляю).
Если в роботе использованы какие-то из языков, встроенных в терминал, то, скорее всего многопоточности нет. Но лишь по тому, что в подобных языках существует на это дело ограничение.