Multithreading discussion

[Salad Viking]

Speaking of multithreading, the next version of C++ is supposedly going to have multithreading support, so maybe someday...

[Graf Zahl]

Threads are already available. That's merely an encapsulation by a standardized API. That part is not the problem. Doom's code was written in a way that having it run 2 threads in parallel on the same data is fundamentally unsafe. A lot of changes would be necessary to make the game logic thread safe.

[Salad Viking]

Ah. I thought you were implying that the threading facilities currently available were not inherently compatible with Doom for whatever reason. What parts in particular are thread-unsafe, and why? Synchronizing can't fix the problem?

[Gez]

If fixing the problem involves enough overhead to negate the performance gain, then the problem isn't solved.

[Graf Zahl]

Synchronizing can't fix the problem?

Not if you have to synchronize every single function. The bad thing is that so many 'purely informative' functions are not just purely informative. And the code still uses some variables that when accessed from 2 threads will throw up. All access to these needs to be serialized - meaning that all critical functions cannot run in parallel which obviously negates the whole idea of using threads.

[Salad Viking]

So you're saying that even a search function can't be multithreaded? Hmm, that's a problem. But I think I read that the sound code runs on another thread. How is that handled?

[randi]

Don't forget that multithreading the game logic would probably completely break all network and demo support as well.

But I think I read that the sound code runs on another thread. How is that handled?

Automatically? I'm not sure how your question is relevant, so I'm not sure what kind of answer you're expecting.

[Graf Zahl]

So you're saying that even a search function can't be multithreaded? Hmm, that's a problem. But I think I read that the sound code runs on another thread. How is that handled?

Most search function work with an object member variable, called 'validcount'. So obviously any access to these functions needs to be serialized to avoid problems. Problems can even occur if this is called recursively which is why some functions use a check array instead already. But even that isn't so easy because there's also other stuff which needs to be access controlled.

The sound code can run in a different thread because it doesn't access the game data - and the few callbacks it has to use to feed the sound streams for certain music formats obviously contain thread control code. Also, most of the thread control is done under the hood in FMOD where you don't see it.

In general you can mutithread code that doesn't have to interact with each other constantly and if it does only in controlled circumstances. That's not the case for the game code.

[Salad Viking]

The sound code can run in a different thread because it doesn't access the game data - and the few callbacks it has to use to feed the sound streams for certain music formats obviously contain thread control code. Also, most of the thread control is done under the hood in FMOD where you don't see it.

Wait - is the only sound code that runs on a different thread the music code? In that case, I understand, because if the game sound code were on a different thread, it would have to access things like the sound source position and reverb environments.

[randi]

All sound is handled in a single thread, which happens to be different from the main thread.

[Graf Zahl]

Wait - is the only sound code that runs on a different thread the music code? In that case, I understand, because if the game sound code were on a different thread, it would have to access things like the sound source position and reverb environments.

The sound code never accesses the game data directly. The game calls an update function each tic that updates the positions of all sound sources and the listener. So what you have is 2 different threads working on different data sets with a relatively small interface (i.e. the FMOD API) to communicate.

Effectively this is a perfect setup for multithreading: You have a worker thread running in the background that for most of the time runs relatively undisturbed without need for being blocked frequently.

[Salad Viking]

Oh, I see. Well, now I understand the problem. It looks like ZDoom won't be seeing multithreading in the near future, though maybe you could look for areas where it can be applied and see if there is some performance gain to be had.

[Graf Zahl]

The only areas where it makes sense would be sound processing (where it's already in) and rendering which thanks to how ZDoom works is not possible.

[DaMan]

How about the nodebuilder? In case someone is playing on a netbook (or possible Windows ARM port) with gennodes on.

[edward850]

How about the nodebuilder? In case someone is playing on a netbook (or possible Windows ARM port) with gennodes on.

Seeing as how all nodes are built before you load the level, and rebuilding nodes on even KDiZD only takes 5 seconds, there is no real benefit from multi-threading a node builder.