Security Monitoring Design in Java Real-Time Multiking Process
content:
Problem Analysis Design Principle Design Implementation End Source Code About the author
There is also a Java area:
Teaching tools and product code and components all articles practical skills
Fanghb@eastcom.com) Eastern Communications Network Research Institute in December 2002 In a series of related multitasking real-time environments, if there is a task failure, it may cause all tasks to generate a chain reaction, resulting in a situation of dispatching out of control. . Especially for core control devices, in order to solve this problem, you must perform real-time monitoring of each task. 1. Problem Analysis In the Java environment, a task is generally booted by a stand-alone thread, and stand-alone threads may call a series of sub-threads. If there is an exception in the execution (there are many reasons for the reason, such as software upgrade, running environment change, system standards, etc.), then the thread will stop running until the next task is re-submitted. For real-time environments, the current task is failed. We cannot predict and completely avoid abnormal occurrences, but can track the status of the task through some technical means, thereby timely discovering problems and returning to normal, reducing loss. 2. Design principles For a real-time task, it is very important to perform efficiency, which means that it is impossible to consider the task monitoring in a very complex manner, even if this is perfect, monitoring code itself will introduce some Abnormal, this requires the monitoring program to be simple and reliable, can discover most issues, and process it in time. A possible simple implementation. We add a monitored "shell" for each task, and the scheduler calls this "shell" to complete the guidance and monitoring of the specific task, which is equivalent to each task has autonomous power. The benefits of doing this:
Dispersion control. No need to modify the scheduling body program, do not increase the complexity of the scheduled process; the control is flexible, and the security is high. For different tasks, different control methods and control parameters can be defined, and the package is internally, flexible, and modifications to individual task control code will not affect other tasks, ie the task control is loose, avoiding errors. Diffusion. Suitable for team development; simple maintenance, convenient upgrade. For new tasks, no need to change the structure of the original scheduler, simply modify the task table and related parameters, which simplifies the code maintenance during the software upgrade while performance.
3. Design implementation of each thread has four states:
The New thread object has been created, but it has not been launched. Once there is a time sliver, the thread starts running when there is a time sliver, and the thread starts running the dead from the Run () method, a thread is dying blocked thread can run, but some The thing is hindering it. The scheduling mechanism does not assign any CPU time until it enters the runnable status in the actual operation, in order to facilitate the description, we re-specify the status of the thread:
The Active thread has been activated. After running the Sleeping thread completes a specific task, it is exited. When you enter the sleep status, the DEAD thread is running an exception, termination, in the death state, according to the above theory, we only need to monitor the Active-state thread, Only only monitoring ActiveD status monitoring, this is a logical simplification of the monitoring module. So how do you implement monitoring modules to monitor specific tasks? There are a variety of monitoring methods for specific tasks. Different monitoring code needs to be used depending on the task, but the structure is basically the same. This is a bit similar to the overload concept of the class. This article attached with a simple example. A Task Perform a simple algebraic operation J = 1 / I, and print the result. We deliberately set an exception trap, so that the arithmetic abnormality except 0 in the execution process, which combines this example to describe the monitoring principle. To monitor A, we designed a monitoring thread M. Some key logical variables are defined in m m: KeepChecking continuous monitoring logo LastStatus Save the last monitoring status MaydeadTimes Monitoring thread MaydeAdtimeout defines the boundary condition of the thread death Dead Trision DEADTIMEOUT Definition to determine the neutral condition of the correction thread In order to adapt to the monitor, add some status and behavior that can be monitored in the A task:
DEAD dead status flag dead =! dead; changing state The entire monitor is expanded around these status flags and behaviors. A task regularly modifies its own Dead flag, Dead is a Boolean variable, in theory, as long as A is not dead, then DEAD is definitely a cycle change (similar to the heartbeat concept), M needs to do changes. Changes. In order to avoid misjudgment caused by accidental factors, we set some counters and boundary values (MayDeadTimes and MayDeadtimeout), and when M found A's possible death exceeds certain limitations, it is determined that A has died, not to wait, As a real-time processing, first log out of the example of A, then restart A (very similar to our computer crash), then enter a new round of monitoring. If the system accidentally causes A death, then it can generally be successfully completed during the subsequent new task startup. However, if there is a version defect in environmental parameters or software upgrades, A may always produce an exception, then do I need to be patiently monitored? An example of an image is: If you fail for 3 consecutive openings, would you suspect that the machine has problems? Of course, you will, then m should also. In order to repeat the A task, there is a statistical, and the M is introduced in the MI. DEADTIMES and DEADTIMEOUT, as the process of the computer, if there is a problem with A continuous N times, can basically Not due to occasional factors, the environment of the code or system is required to be checked. M will issue alarm, notification must be reviewed, then empty A, automatically exit itself. If you set a marker in the core scheduler to accept the alarms, you can have enough reason to terminate the execution of other tasks. It can be seen that during the A task, M assists the maintenance function of the core scheduler. In particular, when the number of tasks is more, the core scheduler can only use the queuing mode to handle the task exception, and due to the difference in complexity of the abnormality, the real-time processing of multi-task exception cannot be guaranteed. It is also necessary to consider the relationship between A and M under normal conditions. After the core scheduler starts the A task, M is in a continuous monitoring state. After the A normally ends the task, A requires notification m to end monitoring, so that when a enters the sleep state, M does not occupy memory space, improve the system Resource utilization. Through the above description, it can be seen that the above monitoring ideas have clear concepts and operability, accounting for less resources, and creates conditions for ensuring continuous stability operation. The specific code is achieved. The results of the operation are as follows:
Abnormal conditions Normal case i = -3: status = truem read a status = true = -2: status = false = true = false = -1: status = truem read a status = truea become Excertion! M read a status = truem ! read A status = trueM read A status = trueA is deaded M is restarting A ____________________________ i = -3:! status = falseM read A status = falsei = -2: status = trueM read A status = truei = -1: status = falseM read A status = falseA become Exception M read A status = falseM read A status = falseM read A status = falseA is deaded M is restarting A ____________________________ i = -3:!!! status = trueM read A status = truei = -2: status = falseM read A status = falsei -1 =:!! status = trueM read A status = trueA become Exception M read A status = trueM read A status = trueM read A status = trueAlert A is unstable, M will stop it (end I = 1: status = truem read a status = truei = 2: status = false = 5: status = truem read a status = true = 4: status = falsem read a status = falsei = 5: status = Truem read a status = truea is ending mm read a s Tatus = true (end) 4. Conclusion By adding monitoring threads to develop task threads, you can solve security monitoring problems in real-time multi-task environments while avoiding over-complex problems with core scheduling threads. Practice has proved that this method is small, accounting for less resources, reliable, and is suitable for multi-tasking environments under complex conditions. 5. Source code: package safethread;
// core scheduler
Public class mythread {
Public mythread () {}
Public static void main (String [] args) {
M m m = new m ();
}
}
// a task thread
Class a extends thread {
Public Static Boolean Dead = False;
M m;
A (m m) {
m = m;
START ();
}
Public void run () {
Try {
For (int i = -3; i <= 5; i ) {INT j = 1 / i; // artificially set the trap during the setting
DEAD =! dead; // activity status
System.out.println ("i =" i ": status =" ";
Try {
SLEEP (2000);
}
Catch (InterruptedException IE {
System.out.println ("a is interfacerupted!");
}
}
M.keepChecking = false; // closes the monitoring thread after normal end
System.out.println ("a is ending m");
}
Catch (Exception E) {
System.out.println ("a Become Exception!");
}
}
}
// Monitor thread
Class M extends thread {
Public static boolean Keepchecking = true; / / Continuous monitoring mark
Boolean laststatus; // Save the last monitoring status
INT MaydeadTimes = 0; // Monitor threads might death counters
INT MaydeAdTimeout = 3; // Defines the boundary condition of judging thread death
INT deAdTimes = 0; // Monitor the number of counter deaths
INT deadTimeout = 3; // Defines boundary conditions that are not normal to determine the thread
A a a;
M () {start ();
Public void run () {
Schedule ();
While (KeepChecking) {
LastStatus = a.de;
Try {
SLEEP (2000);
}
Catch (InterruptedException E) {
System.out.println ("M IS Interrupted!");
}
System.out.println ("m read a status =" a.dead);
IF (LastStatus == a.dead) {
IF ( MaydeadTimes> = MaydeAdTimeout) {
IF ( DeadTimes> = deadTimeout) {
System.out.println ("Alert! A is Unstable, M Will Stop IT");
A = NULL;
Break;
}
Else {
System.out.println ("a is deaded!");
Schedule ();
System.out.println ("M IS Restarting A! / N ___________________________ / n");
}
}
}
Else {
MayDeadTimes = 0;
}
}
}
Private void schedule () {
A a = new a (this);
}
}
About the author: Fang Haobo work in the East Communications AG network Institute in Hangzhou, Zhejiang Province of China. Currently, he is engaged in the design and testing of mobile communication network management software. Prior to this, he was responsible for the development and technology promotion of multimedia video conferencing products, and also engaged in the development of wireless communication product circuit design and switch software. You can contact Fang Haoba with fangb@eastcom.com.
