2) Vega Application Program Main framework
Vega programming is similar to C programming. The actual interface is C, including the complete C language application interface, which provides software developers with the maximum degree of software control and flexibility. There are three main types of Vega Applications on the Windows NT platform: Console programs, traditional Windows applications, and Microsoft Foundation Classes-based applications. However, no matter which type of application, the three necessary steps for creating a Vega application are as follows:
1 initialization: This step initializes the Vega system and creates shared memory and semaphores;
2. Definition: Create a 3D model through the ADF application definition file or through explicit function calls;
3. Configuration: After configuring and setting the Vega system by calling the configuration function, the main cycle of the Vega application is started. The main cycle is used to render the 3D Visual View. It mainly consists of two steps: Frame Synchronization for a given Frame Rate and necessary processing for the current display frame.
The following shows the smallest Vega application:
Main (){
Vginitsys (); // Initialization
Vgdefinesys (MyApp. ADF); // define
Vgconfigsys (); // configure
While (bcontinuing ){
Vgsyncframe (); // synchronous frame
Vgframe (); // in-frame Processing
// Application specific code}
This is a console application. However, Vega is only a function set that contains more than a dozen different modules and does not have window functions (although the Vega function library provides window and event management functions, but these functions are far from enough in practical applications. They lack object-oriented capabilities and do not conform to the popular software design ideas, therefore, a window system is required to complete the Real-Time Simulation Program Design of Vega. In addition, applications with good graphic user interfaces will be more popular on the Windows platform. For window-based applications, the Vega system provides a window initialization function call, that is, you only need to replace the above initialization function vginitsys () with vginitwinsys. This function initializes the display window of Vega by obtaining the window handle.
3) program structure of the MFC-based Vega Application
Considering that Vega functions are written in C ++ and developed on Windows, VC ++ is the preferred development tool. The MFC class library in VC ++ is a very mature class library, especially its document/View-based application framework. It has become the mainstream framework structure for developing Windows applications. The framework structure effectively isolates the data and display parts of the program and maps a document with multiple views. This design method is called the observer mode (observer) in the design mode ). It is an object behavior pattern that defines a one-to-many dependency between objects. When the State of an object changes, all objects dependent on it are notified and automatically updated.
To make it easier for developers to develop an MFC-based Vega application, Vega derives a subclass zsvegaview by inheriting the cview class in MFC. This zsvegaview class provides the most basic function to start a Vega thread, and defines the common interface for a specific application to operate in the form of virtual functions, therefore, your application only needs to derive a new class from zsvegaview and reload necessary virtual functions as needed. From the perspective of the design pattern, it adopts the template method ). The template method pattern is a type of behavior pattern with the intention of defining an operation Algorithm And delay some specific steps to the subclass. This is Code A basic reuse technology. The template method leads to a reverse control structure, that is, a parent class calls a subclass operation, rather than the opposite. Its implementation depends on the polymorphism in the object properties.
1. MFC-based thread Analysis for Vega Applications
By using the template method, you can minimize the workload of developing an MFC-based application. This is the method provided by the Vega system, and its original intention is good, however, the MFC class library is not a class library that supports multi-threaded access. The user-derived subclass starts the Vega thread by calling the runvega () of the base class in the oninitialupdate () function, and transmits the pointer of the derived class as a parameter to the newly started subthread, this is exactly the problem. Because Source code The class space and the thread space during thread running can overlap with each other, that is, different threads can access instances of the same class at runtime-object, the design of the MFC class library does not take into account multi-threaded access. Therefore, it is dangerous to pass the View class cview between threads (according to the "Isa" rule, its subclass object is also a cview object, practice also proves this point. When the document data is changed in the single-document multi-view in the Vega thread and the updateallviews () function is called to update all corresponding views, an access protection Exception error occurs immediately. Looking back at the previous design, we used the derived class cview to embed the Function Code related to the Vega function. In these function codes, the three main steps are to start Vega, the main loop of model rendering and several virtual function interfaces that are convenient for users to expand. The Association of cview only uses the handle of the Windows ports of the cview class. This design actually violates the basic principles of software design: High Cohesion and low coupling. In order to maintain the benefits brought by the template method design and achieve the goal of High Cohesion and low coupling, the best way is to perform the cutting and separation. All data and operations related to the Vega system are implemented independently as a base class cvega, and the user's extended excuses are maintained. In this way, you only need to derive your own class from the cvega class and pass the viewport handle as a parameter. So how can we notify the corresponding sdks to update the data in a timely manner after the Vega thread changes the data? Fortunately, the message-driven mechanism on the Windows platform allows you to use the handle of the view to send messages.
2. Problems in the MFC-based Vega thread
The Vega application can load a 3D scenario model through the application definition file (. ADF. In actual applications, it is necessary for users to switch 3D scenarios without exiting the application when opening the application. From the application framework of Vega, we can see that the framework mainly consists of three steps of its configuration and the rendering main loop. When a user needs to switch to another scenario after opening a scenario, the program is in the rendering main loop, and it should have to be imported in step 2 of the three steps. the third step or three steps of the ADF file are all done again before entering the rendering main loop. Unfortunately, it is not feasible for some unknown specific reasons (not the implementation technical problem of the program structure. Because the Vega system provides function calls in the form of a linked library without source code, from the perspective of designing a software system, to ensure the integrity of the entire system and the consistency of the system's external interfaces, it is absolutely necessary to encapsulate the independence of internal updates and the confidentiality of internal technologies. However, to ensure the above features, it is also essential to provide necessary diagnostic methods for developers. In this regard, Windows API calls and MFC class libraries are very good. They usually return a value in the results of many operations to tell the user whether the operation is successful or fails or an exception occurs, in Windows, a global function is provided to call the getlasterror () operation to determine whether the result of each operation is successful. From the perspective of the design pattern, this uses Singleton, which enables direct access to the function anywhere in the program. However, the Vega system does not provide such a complete diagnostic error method, and most of its operations do not return results. Therefore, the user can only think that this operation is successful. However, once the program encounters a problem, the user will be overwhelmed. In addition, because Vega encapsulates all the interface definitions of a class, all you can get is a pointer to a class that can act as a handle, some inheritance, polymorphism, and message operations related to object-oriented are not clearly reflected in [4]. This is probably related to the purpose of Vega to maximize compatibility with the porting objectives of existing programs.
If you reconfigure the Vega thread before it exits, this will lead to a failure. In this case, when you switch to another thread, the running thread will terminate and re-start the other thread. However, the result is frustrating, with an address access protection error. The main cause of this error is that the referenced pointer is invalid. the pointer refers to the space either released after the space is allocated or pointed to the local address space of other threads. Why is this error? During the second initialization of the Vega system, didn't the previous Vega thread be terminated? Therefore, there must be Legacy problems. After debugging and tracking, the problem lies in vginitwinsys (), the first step of the three-step configuration of Vega. This function is mainly used to initialize the Vega system and create shared memory and semaphores, in addition, it has also done an important thing in the background-that is, it has opened another Vega window sub-thread, the subthread creates a window two of the same size as the corresponding window of the handle Based on the transferred window handle parameter, and overwrites it on window one, this is not mentioned in the Vega Development Guide, so that the rendering window of the Vega system can be embedded in the MFC-based viewport. The creation of this Sub-thread is indispensable, but there is no way to terminate it-it was created inside the Vega function. Because the thread belongs to the process, all threads exit only when the process ends. So even if the parent thread created for it is dead, it is still "active", but some useless parameters such as invalid pointers are reserved. Worse, when the second thread starts, the vginitwinsys () function will not start a new sub-thread, but will continue to keep the originally dead window thread, so the error is doomed.
The effective method to solve the problem can be obtained through some features of the Windows Thread, namely further isolation-implemented using a separate Vega process. From the perspective of the model, this can be applied to the software design as a new design pattern, which may be called the fence pattern (fence ). It blacklists different parts of the same application and accesses each other only through defined interfaces. This minimizes the mutual impact between different parts. From the operating system platform, windows is not a real-time operating system, but a relatively stable system. Because fvss is a real-time virtual simulation system, it processes a large amount of real-time simulation result data in its visual drive module, how to ensure fast and effective communication between two processes in this module becomes a problem.
1. inter-process communication on Windows NT
On the Windows NT platform, the main methods for inter-process communication are Dynamic Data Exchange (DDE), Network Dynamic Data Exchange (NetDDE), and Windows Socket (Windows Sockets ), named Pipes, memory-mapped files, NETBIOS, Remote Procedure Call (RPC), and disk files. In specific situations, appropriate communication methods should be selected to best meet the application performance requirements and facilitate functional implementation and expansion. In the visual drive module, because the Vega process and the MFC main process will run on the same PC, therefore, NETDDE, Windows Sockets, NETBIOS, and RPC are mainly used for inter-process communication between PCs in the network environment. It is obviously not feasible to exchange data through disk files, which makes it necessary to directly communicate in the memory. Because in addition to transmitting a large amount of visual driving data between the Vega process and the MFC main process, some control information must be transmitted, considering the efficiency of implementation, the performance requirements of process communication speed, and the expansion of functions, the use of memory ing files will be the best.
3. Process Implementation of the MFC-based Vega Application
Using file ing objects on the Windows NT platform enables effective data exchange between the Vega process and the main process on the MFC interface. Figure 5 shows the flowchart of two processes in the visual drive module. The user interface control section of the MFC main process is omitted in the figure. Because the isolated Vega process is a console Program (although it also creates its own rendering window), it does not have a message pump and cannot respond to application requirements through the message mechanism. The rendering main loop in the Vega application framework can insert some operations to simulate a message pump to complete the required operations of the main process of MFC, the transferred message can also be stored in the file ing object. On the contrary, because the MFC main process is a window application, it has the function of receiving messages, you only need to directly send Windows messages to it. Figure 6 shows the data structure in the memory ing file that implements the main functions between two processes. So far, using the file ing object in Windows Memory Management not only solves the problem of data sharing and data transmission rate between two processes, it also provides a virtual message pump for the Vega process to complete the required operations of the main process.
