UNITY
Добавлен MF,
опубликован
Суть проблемы
А вся суть в том, что Unity - движок потоко не безопасный. Основную часть его апи не получится вызвать из других потоков, хотя с запуском стандартных C# потоков проблем не наблюдается. И ассинхронная загрузка данных, даже самостоятельная, вполне реальна. Но стоит попытаться вызвать создание объекта, пересчитать вершины меша или другие многие стандартные действия Unity - мы получаем отказ в виде варнинга или даже эксепшна.
Мне в моем проекте было необходимо запускать треды, так как важно было запускать тяжелый по времени цикл, не разбивая его на кадры. Да и сам факт его укладывания в кадр, два или три по времени тоже не был важен... запуск его в Update выдавал весьма плачевный результат... а именно лютую просадку FPS, что логично.
В чем собственно суть, почему в юнити это закрыто? Ну все просто. Представьте, что у вас в игре сталкивается 5 шариков, обсчитывает все физический движок после исполнения FixedUpdate ... и тут, левый поток меняет координаты одного из них, и что мы получаем? Физика уже считается, но шарика на нужном месте нет, он есть в другом, возникают новые колизии, которые, возможно движок и разрулит, но вряд ли. Таким образом мы в лучшем случае получим бардак с физикой на экране, в худшем мы получим вылет билда. И так почти со всем юнити апи, каждая функция, метод имеют место для вызова в общем пайплайне и не должны вызываться вне него.
Авторы движка вполне могли сделать юнити потокобезопасным. Но для этого им пришлось бы повозится с собственной реализацией мультитред апи. К примеру они давали бы людям свою реализацию тредов и приостанавливали бы их в критичных местах... что по сути возможно, но сложно и идеалогически неверно...
Мне в моем проекте было необходимо запускать треды, так как важно было запускать тяжелый по времени цикл, не разбивая его на кадры. Да и сам факт его укладывания в кадр, два или три по времени тоже не был важен... запуск его в Update выдавал весьма плачевный результат... а именно лютую просадку FPS, что логично.
В чем собственно суть, почему в юнити это закрыто? Ну все просто. Представьте, что у вас в игре сталкивается 5 шариков, обсчитывает все физический движок после исполнения FixedUpdate ... и тут, левый поток меняет координаты одного из них, и что мы получаем? Физика уже считается, но шарика на нужном месте нет, он есть в другом, возникают новые колизии, которые, возможно движок и разрулит, но вряд ли. Таким образом мы в лучшем случае получим бардак с физикой на экране, в худшем мы получим вылет билда. И так почти со всем юнити апи, каждая функция, метод имеют место для вызова в общем пайплайне и не должны вызываться вне него.
Авторы движка вполне могли сделать юнити потокобезопасным. Но для этого им пришлось бы повозится с собственной реализацией мультитред апи. К примеру они давали бы людям свою реализацию тредов и приостанавливали бы их в критичных местах... что по сути возможно, но сложно и идеалогически неверно...
Как можно это решить
Тем кто напишет "юзай куротины" - читать дальше не советую, вы не понимаете сути мультитрединга и работы куротин юнити впринципе. Тем кому стало интересно, расскажу суть своего подхода, не претендующего на лавры лучшего, имеющего узкие места, но тем не менее дающего нам почти мультитрединг (во всем, где не юзаются юнити апи, где они используются, приходится немного терять во времени). Я не буду давать готовые классы, дам только куски кода (опишусь сразу, в системе у меня все намного сложнее, идею я пишу на лету и просто для примера. Так как компиляцию это все не проходило, могут быть ошибки... воспринимайте как псевдокод.).
- Создаем свою компоненту вот с таким полями:
object sync = new object();
List<Action> actions = new List<Action>(); в Update вписываем следующее:
void Update(){
lock(sync){ //обеспечиваем потокобезопасность чтения листа
while(actions.Count!=0){ //и исполняем все действия
actions[0].Invoke();
actions.RemoveAt(0);
}
}
}Так же создадим вот такой метод в этом же компоненте:
public void Execute(Action action){
lock(sync){ //обеспечиваем потокобезопасность записи в лист
actions.Add(action);
}
try{
Thread.Sleep ();//усыпляем вызвавший поток
}catch(ThreadInterruptedException){
}finally{}
}Данный метод нельзя вызывать из основного потока, ни в коем случае.
- По сути автомат для исполнения у нас есть, как же нам нужно запускать треды? А вот так:
//customComponent далее это экземпляр вашего компонента
Thread testThread = null;
Action threadAction = () => {
//действия, которые могут быть исполнены в потоке просто так,
//например циклы с расчетами, загрузками и прочим
Thread.Sleep(10000); //мы же для примера просто усыпим наш тред на 10 секунд
//если нужно выполнить какой то код из юнити апи, например создать кубик
GameObject cube = null;
customComponent.Execute(() => { cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
testThread.Interrupt(); //данное действие очень важно в конце всей последовательности
});
//действия, которые могут быть исполнены в потоке просто так, в cube кстати будет лежать наш кубик
}
testThread = new Thread(new ThreadStart(threadAction));
testThread.Start();Как работает идея
Да очень просто. Что делает компонент? Он хранит очередь действий, которые нужно сделать в основном потоке. Что делает метод Execute? Он вызывается из побочного треда, и складывает в очередь исполнения действие и усыпляет поток. В самом действии в конце, есть код, который разбудит тред (та самая важная строчка). Таким образом из треда вы скармливаете небезопасный для вызова код главному треду и ждете его исполнения.
Идеи для развития
все они реализованы по сути, тут же я их просто опишу
- Разделение очередей. Вывести отдельные очереди для Update, LateUpdate и FixedUpdate.
- Автоматизация вызова Interrupt() для действий, дабы не приходилось скармливать его самому действию.
- Добавить возможность выполнения ассинхронных (для вызывающего потока, а не для главного) действий с колбеком.
- Добавить контроль времени, на случай если заданий в очереди много, как то динамически останавливать обработку и откладывать до следующего вызова.
За сим все.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
А вообще да, можно было бы развить эту идею до целого крутого скрипта!
Отредактирован alexprey
Не особо понятно зачем юзать Interrupt
А все, понял, но мне как-то не особо нравится такая концепция, надо тут подумать
Отредактирован MF
upd: такая концепция самая верная в том плане, что система не обрабатывает потоки, которые чего-то ждут. По сути у меня в итоговой реализации в очередь складывается не экшн, а кастомный класс, в котором хранится само действие, колбэк, поток, который вызвал все это великолепие, и функционал для вызова действия и колбэка. Так вот все слипы и интерапты у меня спрятаны и не торчат из щелей. Тут же я просто рассказывал саму концецию =)
Если да, то я всё понял, довольно годно. Делал нечто подобное =)
В том же джейманки модифицировать то объекты из других потоков можно сколько угодно, только в какой-то рандомный момент игра упадет с ошибкой, поэтому можно насоздавать сколько угодно своих потоков, а из них делать application.enqueue(Callable) и в callable экшны, собсно то же самое что и здесь, просто уже продумано.
Отредактирован MF
Doc, нет, треды в юнити вообще не юзались до пятой версии. Все однопоточно. Идеалогия движка такая. Сейчас они узкие места распаралелили, получили прирост, но для нас это все равно однопоточный пайплайн. У них есть варианты как исполнять тяжелый код - коротины. Некое распределенное между кадрами исполнение, посредством yeld return и управляющих инструкций к нему, все при этом остается в главном потоке. Это совсем не то же самое, что треды, думаю пояснять не надо. Насчет вызова и изменений... там все странно. Стандартные методы залочены почти все. НО! Никто не мешает делать свои поля и свои методы компонентам. Их можно юзать, если они не юзают внутренние. Пример: вам нужно, чтоб объект менял свои координаты. По сути вам не важно, что это произойдет реально только перед отрисовкой кадра, или перед обсчетом физики, правда? Вы делаете некое расширение стандартного класа, в котором делаете свои координаты. Их вы менять можете из тредов хоть заменятся, а уже в апдейте каком-либо эти координаты сравнивать с трансформом и накатывать их в случае необходимости. Используя этот подход и идеи изложенные выше, параллельность исполнения кода можно сделать достаточно гибкой и устойчивой к падениям. В любом случае - это вопрос целеполагания.