HighResolutionTimer weird behavior

General JUCE discussion
1

Hello everyone,

I think I’m missing some HighResolutionTimer details. I have sth like below - doSthX() and doSthY() don’t contain any blocking code neither are CPU intensive. I’m testing under Windows only. In debug mode I get frequent deadlocks where timer Y stops executing its callback for some time and then its running again (executing the missed callback executions as if they were queued somewhere). I don’t have this issue in Release build. My first bet was some locks/waitings etc., but I don’t have anything like that in there. Is there any reason why having 2 instances of HighResolutionTimer could cause issues? Or should I keep searching for some hidden locks in my code? I wouldn’t ask here and just go on trying to fix this on my own, but the Debug/Release difference made me completely confused and lost…

class A
{
	class X : public HighResolutionTimer
	{
		void hiResTimerCallback()
		{
			doSthX();
		}
	};

	class Y : public HighResolutionTimer
	{
		void hiResTimerCallback()
		{
			doSthY();
		}
	};

        X x;
        Y y;

public:
        void start()
        {
             x.startTimer(50);
             y.startTimer(50);
        }
};
2

Just a quick update (kind of proofing there’s no lock and blaming the HighResTimer…) - when I replaced the HighResolutionTimer on class Y with Thread class and did my own “timer” in the run() method (class X remained with HighResolutionTimer), I am not having any issues even in Debug mode. Seems like either two concurrent HighResolutionTimers caused issues or there’s sth in the doSthY() that caused that Y highResTimer to somehow pause.

I did another test - with the initial idea (having 2 concurrent HighResolutionTimers) the
hiResTimerCallback on Y doesn’t hang at doSthY() - it returns from that callback and then “hangs” (before calling the callback again). That’s another evidence for no lock in the callbacks.