Yeah, pretty much.
So, you're thinking more like a thread pool with x amount of threads that all take from a thread-safe queue and will perform a task when one enters the queue.
Though personally, I prefer not to use a multiple-producer/multiple-consumer queue as the central point, because these are hard to implement, and it's bound to have a lot of contention if your tasks are small. If possible I prefer to schedule a whole frame's worth of tasks in advance, so that the worker threads know what they're doing for the next frame up-front and don't have to keep popping items out of a queue. These are the kinds of details that a thread-pool framework should implement for you though ;)
Tell the thread-pool that your OpenGL tasks are constrained to thread #0 and don't worry about it. OpenGL calls for rendering should only be a small percentage of your frame time (so they don't need to be split across several cores), and a queue-based thread-pool will automatically re-balanced by doing more non-OpenGL work on the other cores.
I am using OpenGL which requires that the context be set in the thread.
I'm not quite sure what you mean. "Tasks" usually include all the variables that are required to perform the task - as long as only one thread is performing a task, then it's variables belong to that thread.
I also have the question, how am I going to have variables per thread, if the threads will be running virtually any time of task?