You're not understanding the logic.
For starters, it is all usually done from one loop

while( running )
{
UpdateLogic();
UpdateNetwork();
UpdateAudio();
LoadResources();
Render();
}

Now, some of those steps require special care. Your network tick, audio tick, and loader tick all need to use some kind of asynchronous call so that the game doesn't hang when they have work to do. This means using functionality like non-blocking sockets + polling for network code. It could also mean running another thread for your loader code so that you can open files and then decompress them on another thread before passing the loaded data back to the main thread for use.

Bigger games do however do more loops in parallel. You'll often end up with a worker thread-pool that spreads out entity/particle/rendering updates across many cores.

Just as a bit of a warning: if you don't understand the basic form of a game loop, then trying to implement a multi-threaded one might break your brain. Multi-threaded programming can be tricky, and you should only try to do it if you are certain you really need it.

Are you entirely certain that you want your Map::Load to run concurrently with your game loop anyway? It is not designed properly to be a "streaming" type of load (where map data is loaded in the background) so it doesn't really make sense to have it concurrent. Load your map then, when it is loaded, spawn your player and execute the game loop.

Now, if you do want to implement background streaming, you need to completely rethink the problem and the way your map data is organized, so as to be able to stream it in small chunks and implement the streaming as a sequence of operations that can be run in small spurts each iteration, and be interrupted when it is time to move on to another part of the loop.. This, too, can be a complex task, that doesn't necessarily require multi-threading but however it is implemented it requires careful design.

This is pretty much what an earlier poster meant by "ticks". A tick in this context is just some task that is to be executed. The constraint upon a tick is that it not hog too much time, that it pass execution on within a reasonable timeframe so that the other tasks can be performed.

You iterate through the loop. First you update input. This tick must not block; ie, you do not use WaitEvent type functionality, but rather PollEvent. If there are events waiting, you iterate those events and hand them off to event handlers. Those event handlers must also be considerate of the fact that you are in a loop, and not block or take too much time. After events, you handle logic ticks. Just like everything else, this has to be considerate of timing. You can not block or wait, and you have to ensure that things are done quickly. If iterating every single object and updating logic is too slow, you can build a more complex system that updates subsets of objects each time. This might not be necessary for simpler games. Then, you can hand off execution to the streaming loader system. This system would have a queue of tasks to perform (loading level geometry, tiles, whatever) and would be structured to spend some specifiable amount of time completing tasks. When the allotted time has passed, it has to hand off execution back to the loop. AFter all that, you render.

In this typical game loop, concurrency is an illusion. All of these things are happening sequentially, rather than at the same time. However, the timing is such that if you are careful to not allow any one aspect to hog too much time, human perception won't be able to tell the difference.

It is only in the advanced cases, where the sheer amount of processing each turn is too much for a single thread, that multi-threading really shines. Being able to throw more cores or threads at a problem is good for certain classes of problems, but this category of problems is much narrower than one might think. Still, for a streaming world, having a producer thread can be handy. But before you tackle that complexity, profile the be-jesus out of your program and make sure that it is really necessary and that you can't reorganize, restructure, and find some simpler way of solving the problem.

If you want to avoid blocking the main loop, do the reading in a non-blocking fashion. For example, IOCP is a common solution.

It depends on how complex your game is. If your game is small I would just suck all the files into memory at startup into an associative container. All "loads" that occur use in-memory calls to create textures/scripts/whatever. Putting all your data into a zipped archive can speed this up, because generally reading and uncompressing data is faster than reading the data uncompressed. A library like PhysFS can help with this.

Don't over engineer. Get your game working first. Once you have a cool game, then it makes sense to start worrying about reducing load times or removing loading screens.