Как исправить ошибки вызова обработчика событий в другом потоке?

Question

[Dyikot]

Имеется таймер, который считается в другом потоке. У него есть событие Elapsed( можете считать это std::list<std::function<T>>) которое вызывает в том же потоке где и считается.

int main()
{
	std::chrono::milliseconds duration(150);
	Timer t = duration;
	t.Elapsed += &OnElapsed;
	t.Start();
	
	std::this_thread::sleep_for(duration);
}

Ошибки

Ошибки могут появлятся если поставить duration одинаковый для таймера и для sleep_for. В других случаях ошибок не обнаружил. Первая почему появляется не совсем ясно. Вторые думаю связаны с тем что функции в std::function нету? (удалилась уже?)
Возможно ли после окончания таймера вызвать из main потока обработчик не опрашивая специально (т.е. истекло ли время)?

Если нужно вот код счета

void Timer::WaitOnSeparateThread()
{
	std::mutex mutex;
	std::condition_variable conditionVariable;

	_start = high_resolution_clock::now();

	std::unique_lock<std::mutex> lock(mutex);
	conditionVariable.wait_for(lock, Duration - _timeElapsed,
							   std::bind_front(&Timer::IsPaused, this));

	_timeElapsed += duration_cast<milliseconds>(high_resolution_clock::now() - _start);
	_isElapsed = !_isPaused;

	if(_isElapsed)
	{
		OnTimerElapsed(this, TimeElapsedEventArgs{ .Duration = Duration });
	}
}

Comments

[res2001]

Вероятно sleep_for закончился раньше, чем таймер и объект t уничтожился, при этом таймер, возможно, не уничтожился. Что у вас там в деструкторе? Как обрабатывается вариант вызова деструктора, когда таймер работает?

Показывать ошибки в коде CRT - бесполезно, т.к. из этих скринов все равно контекста не видно - перейдите по стеку вызовов к ближайшему вашему коду (если он есть) и там уже можно что-то показать.

[Dyikot]

res2001, Деструктор по умолчанию. Ошибки появляются при вызове OnTimerElapsed

[Dyikot]

res2001, Мне нужно сделать в декструкторе ожидания завершения таймера?

[res2001]

Dyikot, Ожидание, но правильнее, видимо, - снять таймер с исполнения и уничтожить.

[Dyikot]

res2001, Снять таймер получается можно если таймер находится еще в conditionVariable.wait_for(). Иначе нужно ждать.

[res2001]

Dyikot, Вы можете добавить дополнительное условие в wait_for и просигнализировать условную переменную вручную в деструкторе.
Например выставляете в деструкторе флаг timer_disable = true, вызываете signal для условной переменной и ждете на join завершения потока таймера. После возврата из join уже можно завершать деструктор, т.к. поток таймера 100% завершится.
В wait_for дополнительно проверяете этот флаг и если он true - то выходите.
Мьютекс и условную переменную надо сделать членом класса.

[Dyikot]

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

[res2001]

Dyikot, не обязательно, вы этого гарантировать не можете, оно может и в wait_forе застать поток таймера, и он потом спустится уже до вызова OnTimerElapsed.
Так что надо отрабатывать оба варианта.
Предложенный мной выше вариант как раз это сделает. Проверять флаг timer_disable надо сразу после wait_for и завершаться, если он true.

[res2001]

Dyikot, Вообще можно и не делать эту возьню с signal и флагом, а просто в деструкторе вызвать join, но тогда поток деструктора будет ждать завершение таймера все отведенное таймеру время. Если вас это устроит, то можете ограничиться вызовом join.
Но signal с флагом, заставит wait_for завершиться досрочно.
При этом, если ожидание уже завершилось до вызова деструктора, то дополнительный вызов signal и join не дадут больших накладных расходов.

[Dyikot]

res2001, Я сделал если подсчет уже завершился (т.е может еще событие обрабывать, а может и нет) в любой случае жду 1ms (15...), а если еще в conditionalVariable то у меня есть ф-я Reset из-за которой он выйдет и соответсвенно в событие не зайдет и ислючений не будет.

Timer::~Timer()
{
	if(_isElapsed)
	{
		std::this_thread::sleep_for(1ms);
	}
	else
	{
		Reset();
	}
}

Можно еще конечно сделать переменную проверяющая обратывается ли сейчас событие чтобы не жать столько... но думаю у меня будет таймер всегда существовать когда идет счет.

[res2001]

Dyikot, Что если таймеру ждать еще больше, чем 1мс?
В данном конкретном примере - это видимо сработает, но вы же делаете этот таймер не для этого "скучного" теста? Например уберите в main вызов sleep_for(duration).

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

[Dyikot]

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

[res2001]

Dyikot,

думается мне что не будет таких ситуаций когда событие будет выполняется более 15мс

Вы не учитываете возможность вытеснения потока. У нас же везде вытесняющая многозадачность. В любом месте в любое время любой поток может быть вытеснен с исполнения операционной системой и когда он снова получит управление не знает ни кто, может через час или через год или через 10 мс - это все возможные варианты.
Так что эта конструкция sleep_for(1ms) не может ничего гарантировать.
Чем у вас занимается reset я вообще не в курсе.

Впрочем, дело ваше. Все что я хотел сказать я уже сказал.

[Dyikot]

res2001, Возникал еще крайне редкий случай не из-за событий (1 скрин). По итогу сделал thread и conditional_variable как поля в классе. И в декструкторе join.