Войти
UnityФорумПрограммирование

Unity3D: возможно ли менять запеченную текстуру теней в Runtime? (6 стр)

Страницы: 13 4 5 6 7 8 Следующая »
#75
22:14, 25 июня 2020

Alerr
> И взаимодействия тредов, слава богу, нет.
есть) ваш основной тред как-то должен получать результаты. это уже взаимодействие.


#76
(Правка: 22:50) 22:22, 25 июня 2020

kkolyan
> на самом деле - нет.
Ты столько очень много умного написал, а забыл про банальность. Меш который используется не более чем для рендеринга всегда инициализирован, но это не главное. Главное, поток сам себя не запустит до: запуска приложения и определения присутствия этого самого меша, и уже в основном потоке обращения к нему.
Так что - да.

kkolyan
> где рассказывается почему.
Видимо это самое "почему" ты не прочитал в моем ответе. А синхронизация понадобиться только выходным данным.
Alerr
> исключительно чтобы выдать результат, а не менять меши.

kkolyan
А если ты мне хочешь прочитать теорию о том как программируются потоки, то немного ошибся адресом. Хотя бы по той причине, что здесь тысячи пользователей и каждый пытается блеснуть знаниями, показывая одни и те же ссылки, не всегда к месту и не всегда понимая о чем речь.

#77
(Правка: 23:20) 22:58, 25 июня 2020

kkolyan
> есть) ваш основной тред как-то должен получать результаты. это уже взаимодействие.
Ну да, вы правы.

Не подскажете, можно ли  сделать так чтобы потоки дождались когда все потоки закончатся (тока ожидания потоков в главном потоке)?
Похоже что нельзя

Thread[] thread = new Thread[10];
for (int i = 0; i < 10; ++i) {
    thread[i] = new Thread ( () => ThreadProc ( i, ref rayOrigin ));
    thread[i].Start ();
}

for (int i = 0; i < 10; ++i) 
  thread[i].Join ();

UPDATE:

вот такую штуку добавил в конец:

while (true) {
      int counter = 0;
      for(int i=0; i<count; ++i) {
        if (thread[i].IsAlive == false)
          ++counter;
        else
          break;
      }
      if (counter == count)
        break;
        }

Будет ждать пока все потоки не остановятся.

#78
(Правка: 23:46) 23:45, 25 июня 2020

Alerr
Аллокация потока - дорогая операция. Вот так вот каждый кадр их создавать и стопать - нельзя, убьете производительность. Чтобы просто так, "здесь и сейчас" выполнить какую-то операцию в другом потоке, обычно используют тред-пулы. Вообще, это, на мой взгляд, проблему не решает и в итоге будет удобнее менеджить треды руками, но это неплохая стартовая точка чтобы разобраться.

Alerr
> можно ли  сделать так чтобы потоки дождались когда все потоки закончатся
как это в C# "прям красиво" сделать я не знаю, в Java для этого есть CountDownLatch. Судя по всему, вот ближайший шарповый аналог.

#79
0:26, 26 июня 2020

kkolyan
> Аллокация потока - дорогая операция.
Да, спасибо, заметил. Как всегда не получается чтобы сделал и все заработало.
Но хоть обычные треды работают как ожидалось! Передал в них все как надо и работает!
Пробую тред-пулы.

> как это в C# "прям красиво" сделать я не знаю, в Java для этого есть CountDownLatch.
Спасибо!

#80
(Правка: 1:04) 0:48, 26 июня 2020

kkolyan
> вот ближайший шарповый аналог.
Есть еще вариант ManualResetEvent
Ну и стандартный Thread.Suspend Считается устаревшим из за неопределенного результата использования, но его просто нужно использовать в паре с Thread.Finalize.

#81
1:05, 26 июня 2020

foxes
> Есть еще вариант ManualResetEvent
> Ну и стандартный Thread.Suspend
Спасибо!

Просто треды работают и пуллинг работает. Что-то не могу понять как работает пуллинг тредов. Что это такое?
Что есть пуллинг я знаю, но вот что пуллинг тредов дает? Это что, типа очередь которая подается на процессор не сиюминутно, а когда возможно???

Извините, не гуглится как оно работает. Но гуглятся Microsoft примеры с поверхностым описанием.

#82
(Правка: 1:23) 1:08, 26 июня 2020

Alerr
> Просто треды работают и пуллинг работает.
ThreadPool это просто заготовленный "массив" потоков, которые выполняют несколько простых конечных задач так, что все ядра процессора были забиты. Я бы назвал это "потоковый исполнитель" StreamThread (поток потоков).

Предположим ThreadPool имеет 10 потоков. А ты запросил выполнение 20 задач. В результате с начало выполняться 10 первых, а потом после выполнения остальные по мере освобождения потоков. Но так как это задачи часто не синхронизируемые между собой - асинхронные, то тут замута с мютекс/локами не приветствуется. Тут также нельзя делать бесконечные циклы.

#83
(Правка: 6:49) 1:39, 26 июня 2020

foxes
ох.

+ Моя картина нашего разговора

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

Не вижу смысла ссориться, предлагаю мир и конструктивную дискуссию.

PS: Прочитал про модель памяти в C# внимательнее. В частности первую часть статьи (до этого ссылался на вторую, менее интересную). Как я и предполагал - почти все как в Java (кроме volatile loop hoisting и happens before для не-статических readonly полей). Там не так много механизмов гарантии безопасной публикации, и ни под один из них описываемое вами явление не подходит.

#84
(Правка: 5:42) 1:43, 26 июня 2020

Alerr
> как оно работает
Типичный тредпул состоит внутри из очереди задач и воркеров. Каждый воркер - это тред, который в условно-бесконечном цикле берет из очереди задачи и выполняет. И ждет, если задач в очереди нет. Ну а внешнему пользователю пула дается возможность добавить таску в очередь.

Кол-во воркеров может быть гибко настраиваемым - есть разные стратегии.
В случае вычислений эффективнее всего иметь по треду на ядро (возможно, шарповый тредпул по-умолчанию автоматом на это число настраивается).

#85
(Правка: 14:48) 11:56, 26 июня 2020

kkolyan
> тут я предполагаю что у вас в наивное представление о модели памяти CLR
Иначе говоря наивно полагать что даже такая конструкция гарантирует инициализацию меша.

+ Показать

kkolyan
> Там не так много механизмов гарантии безопасной публикации, и ни под один из
> них описываемое вами явление не подходит.
Мощно, 10 лет не знать что последовательное исполнение операций гарантирует инициализацию памяти. Типичная ошибка теоретиков с опытом, это когда пример:

void Init() {
  _data = 42;
  _initialized = true;
}
void Init() {
  _initialized = true;
  _data = 42;
}

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

readdata=CreateData();
Thread1.Run(readData);
Thread2.Run(readData);
Thread3.Run(readData);
Thread4.Run(readData);

bool CreateData()
{
  _data = 42;  
  return true;
}
void Init()
{
  _initialized=CreateData();
}
Или вы хотите сказать что теперь ни один конструктор не гарантирует свое выполнение, до тех пор пока не произойдет очевидного обращения к памяти, а не косвенная передача ссылки на объект. Интересно как же вы собираетесь это отслеживать, если у вас нет таких механизмов даже в одно-поточном режиме.

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

Что это за собеседования? Они не абсолютно одинаковые, но одна из их особенностей — теоретические вопросы, ответы на которые кандидат, по их мнению, обязан заучить наизусть. Такие собеседования отвратительны тем, что дают огромное количество ошибок первого и второго рода. По сути, настолько много, что можно использовать вместо собеседований генератор случайных чисел, и результаты будут приблизительно те же самые.

#86
(Правка: 15:00) 14:56, 26 июня 2020

По делу:

readdata=CreateData();
Thread1.Run(readData);
Thread2.Run(readData);
Thread3.Run(readData);
Thread4.Run(readData);

Это - безопасно, т.к. здесь есть барьер (вы ведь Start имеете в виду, а не Run?). при передаче тасок в другой поток стандартными средствами, барьер между "кодом до" и "кодом в" ставится всегда, насколько мне известно. как именно - зависит от конкретного способа.

Если вы изначально имели ввиду именно это - сорян, из вашего первого сообщения я этого не понял. И наш собеседник, боюсь, тоже мог понять вас иначе.

+ Флейм
#87
(Правка: 15:31) 15:07, 26 июня 2020

kkolyan
> вы ведь Start имеете в виду, а не Run?
Я здесь имел ввиду не Start, а возобновление работы потока.
kkolyan
> Если вы изначально имели ввиду именно это - сорян, из вашего первого сообщения
> я этого не понял.
foxes
> Ты столько очень много умного написал, а забыл про банальность.
foxes
> поток сам себя не запустит
Также как и сам себя из режима ожидания не переведет в режим выполнения.
Как вы себе, без этого всего, а также создание самого потока и инициализацию меша, представляли данную работу? Когда это все гарантированно самим движком написанным на С++. У вас заведомо предвзятое суждение.

kkolyan
> тоже мог понять вас иначе.
Также как и из ваших выкладок можно представить что движек работает иначе. Когда это будет так тогда и разбираться будем. "У семи нянек дитя без глазу"

#88
(Правка: 15:56) 15:35, 26 июня 2020

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

foxes

+ Флейм
#89
(Правка: 16:13) 16:13, 26 июня 2020

foxes

Хотя вот, например. Такое небезопасно (не только чтение результата), но может исправно работать в определенных условиях (не тестил, разумеется, но идея должна быть понятна).

+ Показать
Страницы: 13 4 5 6 7 8 Следующая »
UnityФорумПрограммирование