This is a huge topic and you are right it probably isn't an easy thing to try and answer here, but maybe some hints to help you. You are correct to almost view

This is a huge topic and you are right it probably isn't an easy thing to try and answer here, but maybe some hints to help you. You are correct to almost view multi-threaded applications (or distributed processes really) as essentially a 3d problem. In a single threaded program time is not ever really a factor, sure you want performance so you worry about how long something might take to execute, but that is relevant to the singular flow. In concurrent applications time is a dimension that is essentially uncontrolled and you have to instead rely on state and some form of message handling/passing. Regardless of how it gets implemented, concurrent applications (threads or distributed processes/apps) all have to communicate. Sometimes that is through shared memory, or through shared variables (with associated locks/mutex etc), but in the end they all have to talk -- I've seen files used to communicate etc. So as for where to start when trying to understand an existing concurrent application. Pick one component and find out who it talks to or depends on, figure out how it talks to everyone, and then start your map from there. Instead of mapping function calls you are mapping communication flow and paths. Then within those communication paths each component will have a functional map generally that you can follow like a more traditional application. Some may disagree but to me this is the easiest way to view concurrent or distributed applications. Honestly, once you figure it out, you'll either love or hate it. I personally love it, but it isn't for every problem.