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).
1. Make a call from your C code to the Operating System API for shutdown. Which API call, what permissions you need and what options you have depends on the Operating System.
2. Break out the books and learn to make ACPI BIOS calls, probably more assembler than C. This will do it fast and sure but you may corrupt your OS and will certianly loose any unsaved data if you go this way.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
I am going to add Ribbon Toolbar in My Existing MFC application. As i go through on net,i found that in VS2010,we can create Ribbon Resource using Ribbon Designer Inspite of using Ribbon Classes to create Ribbon Toolbar.
Now, I am using VS2010. I want to know How can I Add Ribbon toolbar to my application which is using old toolbars. Do I need to create Ribbon Resource Independently and then to load in Exisitng Application Or Some other Way to DO it?
Any Help Will be Appreciated.I want to in Right way when I update to Ribbon toolbar.
First of all, without synchronisation objects, you can't rely on anything having happened in another thread.
Second, CAsynchSocket has some inherent design problems (see CSocket considered harmful). You might want to consider rolling your own using the Win32 SDK if you're going to keep it running in a separate thread.
Third, you shouldn't create your CWinThread object directly. Use AfxBeginThread instead.