Hi,

I have a render thread that uses mutexes for accessing data modified in other threads (vertex buffers etc.). I assured that the operations the other threads perform while they have locked the mutexes are pretty short and therefore should not take longer than several microseconds. However, once or twice per second, the render thread has to wait for the mutexes for several milliseconds because they were not released soon enough. This causes stuttering in my game.

Is there a way to prevent that this happens? I already set the other threads' priorities to "idle" and the render thread's priority to "time critical". I tried to set processor affinities for the threads but that didn't help, too.

However, if I only start 3 instead of 12 (my processor's thread count) other threads, the stuttering disappears, but the world loads much slower...

From "therefore should not take longer than several microseconds" to "the render thread has to wait for the mutexes for several milliseconds" is a factor 1000 time.

If mutexes are really locked few microseconds, other threads couldn't even hold the render thread for 1 millisecond, as 12 * few microsecond, is still around 0.01 milliseconds (ah well, let's make it 0.02 to be safe).

That suggests that either your idea of microseconds locking is not true, or something else is happening. Before you blame locking, it is probably worthwhile to understand where these remaining 1.98 milliseconds or so, are coming from (if "few" means 2, otherwise, it's even more milliseconds).

I found the problem: Thread 1 locks mutex A, gets interrupted by thread 2, thread 2 does some work and then thread 1 is re-scheduled and releases the lock on mutex A. So the mutex was locked for many milliseconds instead of microseconds...

I kind of fixed the problem by changing thread priorities. However, I am curious if there is a better fix for this problem. What if I have more than number of processors threads + the render thread running that all at some point lock mutex A?

You want to avoid mutexes and locking all together. You want to be able to queue work up on the render thread from another thread but you shouldn't be creating renderable resources on other threads (a. because you would need a context on that thread to begin with, and b. because it's not where you render that data to begin with).

Create a way for your other threads to instruct the render thread to create the data it needs to render, then the render thread and just check if that data has been built, if so, render it, if not, check if there's instructions to do so and do it, then render it.

This doesn't solve your problem or answer your question but ultimately I think the source of your question is like @[member='SeanMiddleditch'] said.

Your entire render architecture sounds sub-optimal.

The problem is that I have a voxel game with chunks (similar to Minecraft) and I generate these chunks multi-threaded. I definitely need some sort of map for the chunks and I think I need a lock everytime I access the map. I already create the buffers themselves in the render thread, but I need a lock for accessing the data these buffers should be filled with.

Any idea on how to create the chunks multi-threaded but without locking - and remove them if they are too far away?

The problem is that I have a voxel game with chunks (similar to Minecraft) and I generate these chunks multi-threaded. I definitely need some sort of map for the chunks and I think I need a lock everytime I access the map. I already create the buffers themselves in the render thread, but I need a lock for accessing the data these buffers should be filled with.

Any idea on how to create the chunks multi-threaded but without locking - and remove them if they are too far away?

Generally speaking, look at a copy on write model instead of a lock on write model. This should get rid of any vb/ib locking outside of the renderer at the cost of a memory copy when you have prepared all the data and sent it to the renderer which will then perform the lock/copy/unlock without sharing issues. Playing with thread priorities and such things is generally a bad practice as it may work good on one machine and not another due to different virus scanners, services running etc.