I agree with Promit; I have recently been researching multiple contexts for my book and the results are:
#1: It only serves a very focused purpose. If you deviate from that purpose even a tiny bit you would be better off just using a single context.
The steps you have to take to synchronize resources involve unbinding the resource from all contexts and then flushing all contexts.
A lock-step system that would keep each context on their own threads and perform these flushes etc. at their own leisure is not practical, so you will end up moving contexts over to other threads anyway. This means covering the whole game loop in a critical section and a glMakeCurrent() every frame, which is a performance issue.
If you are moving all the contexts over to the loading thread and then restoring them back to their original threads, you may as well just be using a single context; at least then you can avoid all the extra flushing etc.
Which means you can only work with multiple contexts in a way that never requires them to leave their assigned threads.
This means they can be used for and only for loading of resources that previously did not exist. They cannot be used to reload resources or update them. They can’t be used to issue draw calls from multiple threads etc.
#2: Now that it is clear what purpose multiple contexts serve, what is the value of that purpose? Virtually nothing.
In terms of spent CPU cycles, most of the loading process is consumed by file access, loading data to memory, and perhaps parsing it if it is not already in a format that can be directly fed to OpenGL.
The part where you actually call an OpenGL function to create the OpenGL resource is a fairly small part of the process. If it and only it is done on the main thread while loading of everything else happens on a second thread you will hardly see any skips in the frame rate.
Overall, it’s only usefulness is that the contexts can be assigned to a thread once and never be changed, and the only way that can actually work in practice is if all the resources created on the secondary context are entirely fresh new resources (not updates, not delete-and-create-new (it will likely use the same ID for the new resource as the old one which will cause bugs on the main context)), and ultimately that isn’t where the overhead lies.