ПрограммированиеФорумОбщее

Усыпление/пробуждение потока (4 стр)

Страницы: 1 2 3 4 5 Следующая »
#45
12:09, 7 окт 2010

ilkka
> Не, я же имел ввиду вызов из текущего потока.
Отличный контроль за потоками! Сами по себе засыпают где-то.

#46
12:11, 7 окт 2010

Executor
> Я может чего путаю, но вроде поток должен резумится тем потоком, который его
> усыпил, нет?
Нет, это не так.

#47
12:34, 7 окт 2010

KpeHDeJIb
> Отличный контроль за потоками! Сами по себе засыпают где-то.
WaitForSingleObject() - Release ()
VS
SuspendThread(GetCurrentThread()) - ResumeThread()

По моему равнозначно.
Я не говорю, что это правильный/лучший вариант. И тем более так синхронизировать нельзя.
Просто в ситуации, когда поток спит более часа, можно использовать. Хотя от таких вот ситуаций надо избавляться :)

#48
12:54, 7 окт 2010

ilkka
> По моему равнозначно.
А чем вам InterlockedIncrement не угодил? Зачем евенты вообще?
Я на атомарных операциях делал остановку потоков в пуле.

#49
12:55, 7 окт 2010

ilkka
> Просто в ситуации, когда поток спит более часа, можно использовать. Хотя от
> таких вот ситуаций надо избавляться :)
Если он спит час, то траты на создание/удаление потока просто нивелируются,
поэтому можно убить его совсем и не парить никому мозг.

#50
13:22, 7 окт 2010

KpeHDeJIb
> Если он спит час, то траты на создание/удаление потока просто нивелируются
Это может быть какой-то сервер, которому одновременно понадобилось много потоков.
Создать одновременно 1000 потоков, или просто разбудить - разница думаю будет.
Но это все в теории.
KpeHDeJIb
> Я на атомарных операциях делал остановку потоков в пуле.
Ну, остановка и приостановка разные вещи, все таки.
Здесь обсуждается вроде последнее.
KpeHDeJIb
> А чем вам InterlockedIncrement не угодил? Зачем евенты вообще?
Я как раз имел ввиду, что вместо ивентов, в данной ситуации можно использовать Suspend/Resume.
По возможности, лучше только атомарными и обходится.

#51
13:42, 7 окт 2010

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

#52
13:43, 7 окт 2010

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

Тут смотря какие потоки, я предпочел модель со стейтлесс потоками, легкие воркеры.
На нее обычно все удачно ложится если заранее подумать.

#53
14:03, 7 окт 2010

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

#54
14:59, 7 окт 2010

_vasa_
> А TBB по волшебству обходится без этого наверное?

Я без понятия че там делает Intel Threading Building Blocks у себя, ибо его не использую. Кстате, в статье про него речь не идет, описывается механизм синхронизации потоков. Из этой статьи я для себя вынес следующую простую идея - есть время для работы, есть для синхронизации. Когда мы синхронизируемся, никто не работает, вот и все.

>Или использовать существующие механизмы оси/врапперы над ними это безграмотно?

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

#55
15:21, 7 окт 2010

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

#56
15:23, 7 окт 2010

Osiris
> есть время для работы, есть для синхронизации. Когда мы синхронизируемся, никто
> не работает, вот и все.
В общем да, на деле ситуации разные бывают.

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

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

#57
15:40, 7 окт 2010

_vasa_
Счетчики-учетчики, это твое дело, хочешь используй, хочешь нет. У меня все что есть - это пара переменных bool, если вдруг смена значения этой переменной не будет атомарна, то я использую какой-либо флаг с атомарной операцией.

Пока же у меня в движке нет ни одного метода синхронизации потоков, кроме флага. Стресс тестов пока тоже не было, но программа работает на 1,2 и 4 ядерном процессоре без каких-либо замеченных проблем.

ilkka
> Нет смысла синхронизировать физику с рендером, пока текущий кадр еще рисуется.

А я и не буду, я вообще не буду их синхронизировать напрямую. Есть объекты которые не требуют физики, но двигаются, а есть те, что двигаются по физическим законам. Физика у меня будет взаимодействовать с игровым потоком, как и рендер. Данные из физики будут поступать в игровой, из игрового в рендер. Задержка на два кадра незаметна, если их, конечно не всего три :)

>А так он появится только через один кадр.

И от этого всем станет плохо :) Если задержка в отображении на кадр (кстати она стандартна для систем с одним потоком) или два смертельна, то да - моя реализация вам не годиться.

#58
18:56, 7 окт 2010

Executor
> в один прекрасный момент я решаю запаузить поток рендеринга на время
В чём проблема-то ?
Сделай  флажок - пока он поднят рендер  пририсовав кадр уснёт, будет ждать пока он трушный.

, а слова  про Sleep()  (типа тормозит)  чушь ничем не подкреплёная.  Слип просто переключает выполнение на другие потоки/процессы  .

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

#59
20:35, 7 окт 2010

ksacvet777
> , а слова про Sleep() (типа тормозит) чушь ничем не подкреплёная. Слип
> просто переключает выполнение на другие потоки/процессы .

Я не говорил, что слип тормозит, я говорил, что цикл кушает процессорное время напрасно...

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.