1
Window / Re: Understanding why setVerticalSync causes mutex to lock but setFrameRate doesn't.
« on: July 16, 2018, 10:35:40 pm »Splitting logic and drawing into separate threads is not recommended, as properly handling multi-threading is really hard, the overhead caused by synchronization needs to be paid off with even more performance gain and most oft the time, you don't even gain anything from trying to do so.
Is there an easier way to handle asynchronous source content than separating the threads? My issue in this case is it may take up to dozens of seconds for this logic to finish generating a new output and I want to avoid locking the UI/Window from updating during that period.
Your synchronization code for example is already flawed and introduces a race condition where the if statement can validate to true and just after the mutex is locked regardless.
The atomic flag was added for cheap copy efficiency (prevent the texture from updating every frame if the source buffer is unchanged, which is often with this source) not as a way to prevent the mutexes from locking at the same time. The lock race itself is intended as it saves a few MB of RAM over a double buffer and the display thread is nowhere near <1ms causing a missed frame yet.
Why it acts like you experienced, I can't really tell.
Darn, I'll see if I can replicate this in a test project on different build environments and find the root cause. I appreciate you taking the moment to look at this for me - I've sent a project donation on behalf of your time.