Using interrupts is something you do when your program needs to interact with hardware components that trigger these interrupts. Software can trigger only one type of interrupt, and that is by setting a timer. Your problem is not timed, it is controlled by demand, so setting a timer does not fit that problem. using a timer in this situation is like telling a home owner that instead of reacting to the door bell, he should rather check the door every 5 minutes.
I suggest you fire up your preferred search engine and search for the keywords "master slave pattern". This should provide you with lots of interesting links.
The master slave pattern is extensively used for organizing the parallelization of complex tasks. Each slave works (potentially) on its own thread, allowing it to work in parallel with its coworkers. That means telling a slave to work requires sending a message to a different thread or process. Since inter-process communication is rather slow, you should prefer the former.
In most cases it is not necessary for the slaves to live beyond the scope of their tasks. Therefore, the easiest way is to create a new thread for each slave, whenever you need one. The problem you describe assumes a fixed number of slaves however, implying that these slaves' livetimes are not linked to the tasks they work on.
In that case you need a messaging system that allows the supervisor to inform the slaves if and when they are needed, and the slaves to inform the master after they're done. The windows messaging system - as suggested above - should work well for that purpose.
The disadvantage of messages is that the master needs to keep track which of his slaves are busy. Also he'll need to queue the tasks if all slaves are busy, until one becomes available.
Since you need the ability to queue your tasks anyway, a better solution would be to just push your tasks there, always, and let your slaves pick up work items from there whenever they're idle. That way the master doesn't need to know if or who is available for work. He wouldn't even need to be informed every time a slave is done with his work item; instead, the queue could notify him when it is empty, i. e. the entire workload completed.
The only reason not to do that would be if your slaves are specialized to different tasks, but not able to decide for themselves which these are. (e. g. this may happen when the data associated with the tasks come in different formats that the slaves cannot interpret)
I agree with the previous post... why would you want to develop something new for something so old?
If you just want a project, I'm sure you can find other more useful and productive things to work on. Line numbers are hardly ever useful either, I've never had the need for them (I guess if you're having a need to discuss a file with another coder they'd be useful but I've never needed them).