First off, I'd go look at something like
Boost::asio for the background file loading. iirc you can setup callbacks to let you know when the data is done being read.
Secondly, just look into general threading. A background loader consists of only a couple pieces. A thread to do your loading. A structure to encapsulate the functions that need to be run to do the loading. A couple of thread-safe queues to pass requests and loaded data between your threads. The tricky parts of it revolve around figuring out what you can and can't do in the loading thread.
A decent structure would revolve around this process:
1) "pre request". Run the pre-precess step of the loader. All you usually need to do is gather up the data for the request, with considerations for where in the game you are making the request from. Lock your loader queue, enqueue the request in your "outstanding requests" queue. Unlock the queue.
2) "background thread". Lock the queue, pop and item, unlock the queue. Run the loading procedure. This procedure needs to be thread safe! It shouldn't rely on any other part off your game. So, for something like a texture, all you are going to do in this step is reading the file, and maybe decompressing it. For something like an Obj model loader, you could do all the parsing that converts the file into buffers. Unless you know your APIs support multi-threading, don't call them! This means, don't use your OpenGL texture functions here. Don't call your sound API. Don't modify your game state. Don't touch anything outside the data you loaded from the file. When the process is done, lock, enqueue, unlock the loaded data in your "finished jobs" queue.
3) "pre/post update". Somewhere at the start or end of your game loop put the final piece. Before you start a new frame (right after you finish a frame), you want to have a function that locks, dequeues all, unlocks the "finished jobs" queue. From here, run the "post load" function for your resources. Here you can do all your logic that touches the game state, calls non-thread-safe APIs, etc. But all the heavy lifting should have been done in the loader thread, so the commands here should amount to simple registering functions. This would go in place of your "callbackWhenLoadComplete" function, and contain any notifications you need as well.
Things can get a bit easier with thread aware APIs, where you can submit data from the loading thread. But mostly, you just watch out for threading mistakes in general, and keep every "load" function as self contained as possible. And for the places where you can't keep it self-contained, use the "post" function to deal with those parts.
edit:
Some other things to consider. You may want to make functions to kill off a request if it isn't being serviced yet. You may want to add a priority to your requests, so that the resource loading thread will pick the most important resources first (near by objects need to be loaded long before far away object).
It also helps if you bundle up your resources into background object chunks to parse. Instead of issuing a dozen background requests for 8 textures, 2 sounds, a model and a script, you'd issue a request to load a "character chunk". The character chunk would be the equivalent of a zip file with all 12 of those files in it. The loader thread would be responsible for parsing all 12 files out of the zip and then returning the whole character in one go. That way you don't cause the disk to jump around 12 times (SLOW!) while streaming in obviously related parts that all had to be loaded anyway.
[Edited by - KulSeran on September 1, 2010 6:16:47 AM]
