Reduce priority inverting problems and non-deterministic software architecture based on ORBS middleware
Douglas C. Schmidt
Schmidt@uci.edu fsumedh
Department of Electronic & Computer Engineering
University of California
SUMEDH MUNGEE, Sergio Flores-Gaitan, And Aniruddha Gokhale
{FSUMEDH, Sergio, Gokhale} g@cs.wustl.edu
Computer Science Department
Washington University St. Louis
This paper was published in the second issue of the Dutch Publisher Kluwer in 2001 in the second issue of Real-Time System Publications.
abstract
Due to parallel distributed applications For real-time needs, the extension of the ORB middleware to support distributed applications is getting higher and higher. However, the implementation of the traditional ORB middleware, such as the CORBA middleware, exhibits substantive priority inverse and non-determinism that do not adapt to this requirements for real-time systems. This paper provides two new ideas for the research and design of real-time system ORB middleware. 1st, from the previous experience, the conventional ORB middleware cannot support the quality of real-time system service quality. In the second, evaluated the connection and parallelism of the software architecture to comprehensively determine the various strategies in the reducing priority inverse and non-determination in the CORBA ORBS in real time. The views discussed in this article demonstrates the midsea of object-oriented technologies such as CORBA, and supports certain types of real-time applications through Internet.
Keywords: real-time system CORBA middleware, object-oriented service quality guarantee middleware, effective assessment
1. Introduction
A new generation of distributed real-time applications, such as video conferencing, avionics, and process control, need to provide comprehensive statistics and terminal systems with deterministic quality services to ensure reaction time [1], bandwidth and reliability [2] . The trend or tendency to discuss below will change the development of distributed real-time applications and terminal system software development technologies.
Centralized enhanced middleware and integrated architecture: There is currently a tendency to study and development projects in real-time systems that can be used to integrate applications using reusable components based on object-oriented intermediate parts [3], thereby developing a real-time system A general model architecture. The purpose of middleware is to improve system efficiency and reduce cycle and different suppliers to integrate software development efforts needed to make reusable components.
Centralized Enhanced Service Quality Assurance Middleware and Development System: Open Distributed Application Components with Perfect Statistics and Determining Properties [4] implements a single chemical process, so for remote processes that implement this collaboration process The demand for calling and communication technology is also gradually increased. With the variety of content, these components must meet the functionality of the application and the requirements of the quality assurance system.
Concentrate-enhanced standardization and in line with leverage for hardware and software for CTOS embedded real-time multi-task operating systems: In order to reduce training, transplantation, maintenance costs, the development of CTOS hardware and CTOS operation The development speed of the system has also put forward higher requirements. Some hardware and software international standards for CTOS are currently issued by quality assurance system standards.
One of the specially worthy of interest is the CORBA (public object requesting agency (scheduling) program architecture) specification for OMG (Object Management Organization)) [5]. CORBA is a middleware that allows customers to call remote object methods without care of the specific location of the object, written in what language, running on how to operate on how to connect, and interconnect distributed object communication and network Type of protocol [6].
Recent standard CORBA has made new progress in real-time systems [7] and embedded systems [8]. Some OMG groups, most of them have strong interest in real-time systems, and are extension of the CORBA standard to support distributed real-time applications. The target of standardized real-time system CORBA components is to make real-time applications can be linked by embedded systems or a variety of different distributed environments, such as Internet. However, the development, standardization of the distributed real-time system ORB middleware is still difficult, although the above OMG group (RT SIG) has made a large amount of fruitful work. Extensive development, and standardized distributed real-time system ORB middleware runs very little on CTOS operating systems and related hardware. Traditional CORBA ORBS is generally not suitable for distributed real-time applications that are very sensitive to performance. The main reason is that they [1] lack the service quality guarantee of the interface specification, [2] lack the environmental protection environment, [3] ] The planning characteristics of the real-time system and the severe performance of [4] and [9] are unpredictable.
Although some operating systems, network protocols support real-time system timing arrangements, but there is no complete end-to-end solution [10]. Moreover, research on real-time ORB terminal system strategies is very rare, and not inserted. For example, service quality (QoS) studies are only starting to refer to critical needs and modeling for ORB intermediates in the network and operating system layers [11].
From a historical point of view, the QoS study of the high-speed network, such as ATM, to a large extent, focus on the distribution of virtual circuit bandwidth [12]. Similarly, the study of real-time operating systems will be inevitable.
The priority inversion and dispatch mechanism in the synchronous state of multi-threaded applications [13]. Therefore, a very important open research topic is to determine how to best deploy QoS results from the network layer and operating system layers to many programming models familiar to real-time application developers using ORB middleware.
This paper organizes: Part 2 outlines the basic factors affecting the performance and predictability of real-time ORB terminal system; Part 3 describes the software system of real-time ORB core, focusing concentrated in selectable ORB core communications and connectivity Software system; Part 4 represents an empirical point of view, systematically tests four different periods of CORBA of various optional ORB core systems: CORBAPLUS, Minicool, MT-ORBIX and TAO; Part 5 Comparison With our research results and related practices; Part 6 is mainly ended, and provides a complete set of CORBA reference styles for the end of the comment.
2. Factors affecting real-time ORB terminal system performance
Meeting QoS performance requirements The next generation of distributed applications is not only defined to define a set of interface definition languages (IDL) or add a set of first-type real-time system timing control systems in the operating system. It also requires a complete set of two-dimensional grid-like full ORB terminal system system, which transmits end-to-end information with QoS guarantees throughout the multi-level number of distributed systems [10]. In an ORB terminal system, the key hierarchy includes a network adapter, an operating system input / output subsystem, a communication protocol, an ORB middleware, and a high-level service indicated by Figure 1.
The focus of this paper is the software architecture suitable for real-time ORB cores. The ORB core is a managed transport connection in the CORBA reference model, sending a customer request to the object adapter, and returns a response (if needed) to the client. And it also performs the communication architecture used by the endpoint (multiple) signal separator transmission and the application. Figure 1 illustrates how the ORB core is integrated with other ORB groups. Appendix A more specifically describes the standard CORBA components.
More complete, 2.1 segment describe the performance original information based on the ORB terminal system. Section 2.2 describes a key reason for priority inversion and non-deterministic factors affecting the predictability and utilization rate of real-time ORB terminal systems. After the overall summary, the Section 3 gives an in-depth discussion of optional ORB core communications and connectivity systems.
2.1 Original information based on ORB terminal system performance
Our measuring the experience of throughput and delay in CORBA [14, 15, 16, 17] indicate that performance overhead in real-time ORB end systems is derived from the following components:
1. Network connection and network adaptation card: These components handle the connection and bandwidth of the heterogeneous network, which greatly increases the delay and causing performance. The inefficient design of the network adapter card will cause queuing delays and loss datagrams [18], which is unacceptable for some types of real-time systems.
2. Communication protocols and integration of I / O subsystems and network adaptation cards: inefficient protocol implementation and unautreating integration of I / O subsystems reverse the performance of the end system. Specific factors that cause invalidity include protocol overhead caused by flow control, blocking control, rehabilitation strategy, and connection management. Similarly, the lack of appropriate integration of the I / O subsystem produces excess data copies, debris, reloading, context switching, synchronization, inspection, and calculation, multi-transfers, grouping, and unlocking [19].
3. Implementation of the ORB Transport Protocol: ORB Transport Protocol, such as IIOP Protocol [5] and SFP [20] protocol, which causes great performance overhead and priority. The special factors to be responsible for these reversed include inappropriate connection management strategies in the ORB protocol implementation, inefficient end system resource sharing, and excessive synchronous overhead.
4. ORB core implementation and integration with operating system services: A improper design of ORB core produces excessive memory access, low cache hits low, allocation / debounce, and context switching [21]. Conversely, these factors increase delay and jitter, which is unacceptable for distributed applications with determined real-time demand. Causes inefficient specific ORB core factors include: data copy, split / reload, context switching, synchronization, check, and socket multi-channel forwarding, timer processing, request multiplex, group / unlock, fragmentation, error check , Connection and concurrency structure. Many of these inefficies are similar to '2' because they all occur in user-level rather than core levels (note: relative to the operating system), however, ORB implementations are often more convenient to handle them.
Figure 2 shows the key factors of the above-described influence of the ORB system performance and how to do optimization in practical work to reduce priority inverse and uncertainty. At the low page, we describe components that should be mainly responsible for priority inversion and non-determinants in the ORB terminal system.
2.2 Causes of priority inversion and non-determining factors in the ORB terminal system
It is very important to minimize priority inversion and non-determination factors in the execution time of the control real-time operating system and ORB middleware. In the ORB-side system, priority reversing and uncertainties are typically derived from resources shared between multiple threads or processes (Note: High priority threads may wait for low priority thread release due to competition, but must wait for low priority thread release Resource). The common resources of the commonly shared ORB terminal include [1] TCP connections for a CORBA IIOP protocol engine to transfer requests through the transfer of the client and server transmission endpoint [2], process range of dynamic memory manager [3 ], And internal ORB data structures [4], such as transferring endpoints and multi-purpose mapping of client requests. The following description is a key source of priority reversing and uncertain in a conventional ORB terminal system.
2.2.1 Operating System I / 0 Subsystem
An I / O subsystem is a component in the operating system, responsible for creating a coordination application and access to low-level network resources and operating system resources (Note: Applications and ORBs are one side, the operating system and the network are the other party, The I / O subsystem is a civic coordinator), including device drivers, protocol stacks, CPUS, etc. Create a high performance, the key challenge in the real-time I / O subsystem is [1] to minimize context switching (such as hanging a thread to perform a context switch caused by another thread) and synchronization overhead, [2] To implement QoS guarantees, while minimizing priority reversal and uncertainty. When a thread being executed voluntarily or does not voluntarily abandoning its CPU, a context switch is triggered, depending on the operating system and hardware platform of the next layer, one context switch may need to execute hundreds of instructions. Refresh the register window, refresh the memory cache, refresh the instruction line, and refreshed the buffer next to the conversion. Synchronous overhead comes from blocking mechanisms, these mechanisms serialize access to shared resources, typically shared resources such as I / O buffers, message queues, protocol connection records, and in protocol processing, as in protocol processing Multi-way forwarding mapping.
The I / O subsystem such as Solaris and Windows NT is not performed, and the priority protocol is processed. Therefore, the prior priority data report is delayed due to the arrival of the higher priority datagram, but is processed in the order they arrive, not according to their priority Has been processed.
[22] Check the key priority reversed problem caused in the I / O subsystem, and describes how TAO's real-time I / O subsystem avoids many forms of priority reversal by collaborative scheduling user-level and core-level real-time threads. . Interestingly, the results in the fourth quarter show that most overhead in the ORB terminal system does not originate from the ORB core in the I / O subsystem in the I / O subsystem. Software structure.
2.2 ORB core
The core of an ORB is a component in CORBA, which implements the General ORB Protocol (Giop) that defines (which can be inter-heterogeneous) ORB interoperability format. The ORB core establishes a connection and implementation of the concurrent structure that handles Giop requests. The following discussion describes the root causes of priority reversal and non-deterministic in the usual ORB core implementation.
Connection structure: The connection structure of the ORB core defines how the request is mapped to the network connection, and the performance of the ORB real-time system has mainly impact. Therefore, a key challenge for developers of real-time ORB is to select a connection structure that can effectively utilize a transport mechanism of an ORB end system. The following discussion describes the root causes of priority reversal and non-determinant from the usual ORB core connection mechanism:
l Dynamic Connection Management: The usual ORB is dynamically established in response to customer request. However, dynamic connection management can cause great runtime overhead and priority to reverse. For example, a high-priority customer may wait for a low priority customer to complete the connection, and the time required to establish a connection may vary wide, range from the microseconds to millisecond, depending on the load and network of the end system Crowness.
The overhead of the connection is difficult to determine, for example, if the ORB needs to be dynamically established between a customer and a server, it is difficult to provide a reasonable guarantee for the execution time, because this time must be included. (Chang is a change) connection establishment time. Moreover, the connection establishment often occurs outside the usual end-to-end operating system QoS protocol implementation mechanism, such as retransmission timer [25]. In order to support real-time QoS requirements of the application's deterministic QoS, the ORB terminal system often must pre-allocate the connection in advance.
l Connecting multiplexing: Typically ORB core often references all objects of a servo program within a service process to share a single multiplexed TCP connection, see Figure 3. The purpose of connecting multiplexes is to minimize the number of connections per servers, such as to improve the amplifiable of the server on TCP. However, the connected multi-multiplexed returns produces a very large data level priority reversed and synchronized overhead, see the following chapter.
Concurrent structure: ORB core concurrency structure (it defines how to map the request to thread) also has great impact on its real-time behavior. Another key challenge for real-time ORB developers is to choose an identity architecture that can effectively share an ORB end system and its application operations in one or more threads. The following description is a key root source of priority reversal and non-deterministic displayed by the usual ORB core:
l Bidirectional operation response processing: In the client, the usual ORB core of the two-way operation may cause great priority to reverse. For example, using a multi-line multi-thread ORB core that is waiting for a copy of a server to block a higher priority thread that is waiting for a copy of the same server, it will cause priority to reverse.
l Thread pool: In the server side, the Alb core concurrent structure often uses the thread pool [26] to select a thread that handles an entry request. However, the usual ORB does not provide a program design interface that enables real-time applications to assign threads in this pool. Therefore, the priority of a thread in the pool is often not suitable for the priority of the servo program that will eventually execute the request. A improper design of ORB core increases the possibility and duration of priority reversal and uncertainty [27].
2.2.3 Object Adapter
The object adapter is a component responsible for the CORBA system to serve as a component that serves the corresponding request. A standard adaptation to Giop requests contain identification of their objects and operations. Each object is identified by an 8-byte object flag, and of course the object flag is unique. Each operation is represented as a set of strings. As shown in Figure 4, the ORB terminal system must take the task of the following.
Step 1 and 2: Start from the network physical layer, through the data link layer, and the transport layer to the application layer boundary (for example: interface cover), the data is transmitted to the ORB core in one server process, operating system in this process Protocol Stack Division Timely Take Information Request Information
Step 3 and 4: ORB core Use address information to locate the appropriate PoA interface and service on customer object identity. The POA interface is hierarchically organized. Therefore, the POA of positioning the designated service allows us to focus on a series of taps in nesting POA layers.
Step 5 and 6: The POA interface uses the method name to locate the appropriate IDL framework. This framework performs the column collapse of the request parameters and performs the kernel thread UpCall to supplement the developer's work to perform the object.
The conventional deep ORB terminal system as shown in Figure 4 is generally not suitable for real-time systems with high performance requirements, as described below [28]:
Efficiency of gradually decreasing: During the ORB terminal system processing, the hierarchical discharge generates additional internal tables that must be induced by customer requirements, thus reducing performance. Sub-access customer requests in all of these levels are very expensive, especially when a large part of the operation occurs in an IDL interface, or many services are managed by an object adapter.
Gradual growth priority inversion and non-determinism: Since the QoS information of the service layer QoS information is unable to achieve the low-level device driver and the I / O subsystem of the ORB terminal, the layered demultiplexing can result in priority. Invert. Therefore, an object adapter may decry the data packet according to the FIFO order they acquire. The FIFO demultiplex will result in higher priority packets to wait for low priority packets in uncertain time to be demultiplexed and assigned.
Traditional CORBA execution will lead to severe advance solution issues. For example, [15, 17] exhibits a traditional ORBS with 17% of server time to process the reuse request, unless the advance problem can be lowered and solved Reuse can exhibit predictability. For real-time systems, ORBS cannot make unified, and upgraded QoS guarantees. [14] Now selectable ORB decompression technology describes how TAO real-time object adapters provide the most ideal decompression policy to continuously perform. The decompression policy used by TAO is used to remove unnecessary hierarchy in accordance with the TAO adapter to avoid priority inversion.
3 selective ORB core communication and connection architecture
A considerable number of ordinary ORB core communications and connection architectures are described in this section. Each system can be performed by one or more CORBA for commercial and research. Below, we evaluate how each system is how to manage the collection of ORB terminal components and application operations. Part 4 is exemplified from quantity illustrate how efficient and predictability of these optional performances in practical applications.
3.1 Obchible ORB core connection system
There are two general strategies for connecting structures constructing an ORB core: multiplexing and non-multiplexing. Focus on the client connection architecture, we describe and evaluate the following various design choices.
3.1.1 Decomposition Architecture
Most of the traditional ORBS decomposes all client requests that are dissipated from a connection with a process. This multiplexed connection structure is used to build a delative ORBS by minimizing the number of TCP connections that is opened to each server. However, when multiplexing is used, a key challenge is to design an effective ORB core connection structure that is effectively supported by Compact Read and Write operations.
TCP provides non-type TCP to provide non-type byte stream data transfer semantics. Therefore, multiple threads do not do read and WRITE in the same SOCKET, similarly, the write operation of a Socket shared in an ORB process must be serialized, and serialization is usually written through a customer process. Before sharing socket, you must get a lock in such a way.
For single operation, it is not necessary to set additional lock mode or process after a request is issued. For two-way multiplexing for sharing information, the situation becomes complicated. However, in this case, the ORB core must allow multi-threaded consecutive formulas to perform 'read' operations on the Socket terminal.
If the server's response is multiplexed by a single TCP connection, multiple threads cannot be read at the same time, but the ORB core must send and respond to the servo program with the servo program with the original customer request. A giop serial number returned together, multiple forwarding into an entry response to the appropriate customer thread.
There are several common ways to achieve multiplexed multiplexing to allow concurrency read and write, as follows:
Active connection structure:
l Review: One of the strategies is to use the movable architecture shown in Figure 5. An application thread calls a dual multiplexing that enters the queue of ORB.
(1) There is a separate thread in the ORB core to serve this queue.
(2) and perform WRITE operations on a Socket selected by the ORB thread in numerous sockets.
A Socket selected by the ORB thread: A client may have many Socket connections with many servers.
(3) The ORB thread performs SELECT operations on this socket, waiting for the server's response.
(4) and will be added to join a message queue.
(5) Finally, the application thread reaches the queue's reply message.
(6) and send it back to the requester.
l
The advantage of active connection structure is that it simplifies the implementation of ORB by using an identical queuing mechanism. In addition, if each Socket is datastly, that is, the data report that does not receive different priority data reports on the same socket, the active connection can process these datagrams that these datagrams will not cause the request grade. Level inverted [22].
l Defect
The disadvantage of this structure is that the active connection causes additional context switching when it involves two-way operations. Therefore, in order to minimize this opening, many ORBS use a variant of the active connection structure, as follows. Leader / follower connection system
(1). Another model of retrospect alternate activity architecture is a leader / follower connection system shown in Figure 6. As in the past, an application thread calls a dual-way multiplexing.
(1). Not the request is ranked in an ORB message queue, but it is directly transmitted by Socket.
(2). Call the write operation by the application thread, and no thread in the ORB core is dedicated to all Socket I / O in the Leader / Follower structure. Instead, the thread waited in the first waiting response message in multiplexing will be blocked.
(3) This thread is called leader. To avoid the Socket's byte stream deterioration, only the Leader thread can perform SELECT on Sockets so that all the client threads that follow the Leader response from the shared socket will block the signal lights managed by the ORB core. If you respond to the server in the server, this strategy is best because there is no unnecessary processing or context switching. Since the response may arrive in a non-FIFO order, the next response from the server may belong to any customer thread that is blocked on the signal. When the next response from the server arrives, the Leader reads this answer.
(4). It uses the serial number returned in the Giop Answer Package to determine the correct thread that receives the response. If the response is an answer to Leader's own request, the Leader thread releases the next FOLLOWER on the signal light.
(5). And return to its calling program.
(6). This next FOLLOWER thread has a new Leader and performs and blocks it on the SELECT operation.
If the answer is not to the Leader thread, the Leader thread must signal the appropriate FOLLOWER thread and then get the thread that is notified, read its response, and returns to its calling program. Instructions, the Leader thread continues to wait for the next response in Select.
l Advantages: The advantage of the leader / follower connection system is that it can minimize the response content exchanged in the FIFO order.
l Defect: The defect of the leader / follower model is that complex logic execution can generate a lock operation and priority inversion. Lock operation is generated due to the demand of the original language when the request is sent. When the priority of the waiting thread is not paid attention to the priority of the leading thread, it is polymorphically to send a response to the customer thread and may have a priority inversion.
3.1.2 Non-Polymult Connection System
Review: One technique for minimizing ORB core priority inversion is to use a non-polymorphic connection system, such as shown in Figure 7. In this connection system, each customer thread maintains a repeatedly generated connection to store [30] service for thread-level storage. Each thread having independent priority maintains an independent connection, such as P1, P2, P3. So, when a two-way connection is called (1), they do not share the Socket terminal with other threads. Therefore, write (2), select (3), read (4), and return (5) operations may occur without other threads within the process to appear in ORB core resource competition.
Figure 7. Non-multi-state connection system
Advantage: The most important advantage of non-polynormal connection system is that it can protect end-to-end priority and can minimize priority inversion when passing through the ORB terminal. Not only that, since the connection is not shared, this
Design can be low synchronized due to the transmission and acceptance of the two-way request [31] when the ORB core does not require additional lock operation.
l Defect: Defect of non-polymorphic connection system is that it can use a larger number of Socket terminals than the polymorphic connection model, which may increase the storage capacity of the ORB terminal. Moreover, this method is not determined by the number of priority. Therefore, this is the most effective way to configure real-time programs, such as electronic device computing systems [22], which can process small number of connection and priority systems, while each priority system points to an OS thread priority. 3.2 Select ORB Core Communication System
There are many components orb [26] strategies for communication systems. As described below, we describe a number of optional ORB core communication systems, focusing on server-side communication.
3.2.1 Worker Thread Pool System
Review: This ORB communication system uses a design similar to the active connection system described with 3.1.1, as shown in Figure 8, the components of the working thread pool include I / O threads, a request queue, and a worker thread Pool. I / O Thread Select (1) Socket end, read (2) New customer request and insert them into the tail of the request queue. The worker thread in a pool will take the next request from the queue header (4) and send (5) it.
Figure 8. Server-side working threads pool communication system
l Advantage: The biggest advantage of worker thread pool communication system is the flexibility of the implementation. In particular, the request queue provides a straightformer / consumer design pattern.
Defect: The main disadvantage is that excessive context switching and excessive management queues need synchronization, and the priority caused by the connected multiplexed multiplexes. A high priority request to arrive later will wait for a low priority request until it is processed. Moreover, if the priority of the original read request is lower than the priority of the servo program that processes the request.
3.2.2 Leader / Follower Thread Pool System
l
Review: The leader / follower thread pool system is the best system for workers thread pools. This is similar to the leader / follower connection system described in 3.1.1. Assign a thread pool, (1) Select a Leader thread, which performs SELECT on all servo programs of the server process (listening is available in all of these connections), (2) When a request arrives, this A thread reads it in an internal buffer. If this is a legitimate request for a servo program, a Follower in the pool is released, thus becoming a new Leader, (3) and the original Leader assignment is called, (4) The upward call is assigned Later, the original Leader became a FOLLOWER and returned to the thread pool. The new request is queued in a socket endpoint until one of the threads in the pool is available to execute the request.
Figure 9. Server-side leader / follower communication system
Advantages: Compared with worker thread pool design, the main benefit of the Leader / Follower thread pool structure is minimized by the overhead of the context switch caused by the entry request, because reading a requesting thread is also a thread that handles the request, and Not a thread read request, but by another thread to handle the request (this happens to handover).
Disadvantages: It is logically generated excessive blockade overhead and priority inversion. And compared to, it is difficult to implement.
3.2.3 Thread Frame System
Review: A very flexible way to achieve an ORB concurrency structure is to make the application developers can customize the Hook method provided by a threaded structure, constructing a method of constructing this framework as shown in Figure 10. This design is based on the MT-ORBIX thread filter framework, which implements a variant of Chain of Responsibility Pattern [32].
In MT-ORBIX, an application can install a thread filter at the top of a filter chain, the filter is an application programmable hooks, which can perform many tasks, the public tasks include interception, modification, or check each entry ORB request. In the thread frame structure, (1) read a request from a connection thread in the ORB core to the endpoint of a socket, (2) and queue the request queue from the ORB core. (3) The other thread then removes the request from the queue and sequentially passes this request through each filter in the chain. (4) The top filter, that is, thread filters, determines the thread that handles this request. In this thread pool model, the thread filter will request a queue to a queue with a thread service with the appropriate priority, then pass the control back to the ORB, and the multi-forward and assignment of the ORB performs operation. Call up.
Figure 10 Server-side thread frame communication system
Advantages: The main advantage of a threaded framework is its flexibility, thread filter mechanisms can be programmed by the developers of the server to support various concurrent policies. For example, in order to implement Thread-Per-Request [33] policy, the filter can derive a new thread and pass the request to this new thread. Similarly, this MT-ORBIX thread framework can also be configured to implement other concurrency mechanisms such as Thread-Per-Object [34] and thread pool [35].
Defect: There are several defects for thread frame design. First, since only one single filter chain is only, the priority may occur because each request must pass the filter chain in the fifo order. Second, there may be multiple level FIFO queues in the ORB terminal system, so a high priority request may be processed after several low priority requests that have reached earlier. Third, the versatility of this thread frame can greatly increase the overhead of the blocking, as you must get the lock in the queue that requests the request to the appropriate thread.
3.2.4 Reactor-Per-Thread-Priority System
l Review: Reactor-Per-Thread-Priority Structure Based on Reactor Mode [36], it integrates multiple forwarding of the transport endpoint and the corresponding event handler. This thread structure associates a set of Reactors in the same set of threads in different priorities.
As shown in Figure 11, the Reactor-Per-Thread-Priority structure includes a plurality of pre-allocated Reactors, each of which is suitable for each priority in the ORB (such as P1, P2, P3, P4) as its own Real-time control thread is associated.
In each thread, (1) The Reactor multi-channel forwards all access client requests to the appropriate connection processor, such as Connect1, Connect2, etc. (2) and connect the processor read request and (3) assign it to Its thread priority performs a servo program for uplink calls.
Figure 11 Server-terminal Reactor-Per-Thread-Priority Communication System
Each Reactor in an ORB server is also associated with an Acceptor, which is a factory that listens to which thread is connected to the client on a specific port number and establishes a connection processor to process Giop requests. In the example of Figure 11, there is a Lister port for each priority.
Advantages: The Reactor-Per-Thread-Priority structure has the advantage of minimizing priority reversing and uncertainty. Moreover, it requires the servo program to be blocked only when the servo program is interacting with different thread priorities, reducing context switching and synchronous overhead. In addition, this concurrency structure also supports scheduling and analysis techniques associated with the priority rate, such as rate-fixed scheduling (RMS) and rate fixed analysis (RMA) [39, 40]. Defect: The disadvantage of the Reactor-Per-Thread-Priority structure is that it is serialized all customer requests for each Reactor within a single control thread, which reduces parallelism. To alleviate this problem, a variant of this structure associates a thread pool with each priority, although this will increase the potential parallelism, it will cause greater context switching and non-determinism, this situation It is unacceptable to some types of real-time applications.
3.2.3 Integration Connection and Communication System
Figure 12 end-to-end real-time ORB core software system
The Reactor-Per-Thread-Priority structure can be seamlessly integrated with non-multiplexed connection models to provide the priority of the middle end of the real-time ORB end system. In this pattern, Acceptors listens on ports corresponding to 20 Hz, 10 Hz, 5 Hz, and 1 Hz rate, once a customer is connected, its Acceptor creates a new Socket Queue and a connection processor serving the queue. The I / O subsystem uses the port number contained in the arrival request as a multi-way forwarding keyword to associate the request with the appropriate Socket queue. Each queue is served by an ORB core thread running in an appropriate priority.
Reactor-Per-Thread-Priority Structure and Non - Dive Demolition Connection Structure Based on "Emergenly" multi-way forwarding request to the appropriate real-time thread of this priority target servo program, will pass throughout the distribution The priority of the formula ORB end system is minimized. It will be explained in Section 4.2, which is ideal for real-time applications with certainty QoS requirements.
4. Real-time ORB Core Performance Experiment
This section describes the results of several commercial and research-type real-time system performance, including Iona MT-ORBIX 2.2, Sun Minicool 4.32, Expersoft Corbaplus 2.1.1, and tao 1.0. MT-ORBIX and CORBAPLUS are not true in true, they are not external design to support real-time QoS demand applications. Sun minicool is a subclass of Cool ORBs designed in a particularly small memory embedded system. TAO is an ORB component designed by Washington designs specially supports deterministic and maintaining service quality. Tao has been applied in many companies' products, such as Boeing [37], SAIC, LOCKHEED MARTIN, AND RAYTHEON.
4.1 Benchmark Test
This section describes the system test criteria we designed to determine the delay time and throughput, and the priority inversion and non-definition factors in the ORB terminal system. The test temperature we have elaborate is shown in Figure 13. The hardware and software environment used are as follows.
4.1.1 Hardware Configuration
We did use a Fore system ASX-1000 ATM switch to connect 2 multiprocessor UltraSPARC-2, and the operating system used is Solaris 2.5.1. The port of the ASX-1000 is 96, and the OC12 has 622Mb / s exchange speed. Each Ultrasparc-2 includes 2 168 MHz Super SPARC CPUs, and a 1M Cache Cache. Solaris 2.5.1 TCP / IP Protocol Stack uses the streams communication architecture [41] to perform the operation.
Each UltraSPARC-2 has 256m RAM and an ENI-155S-MF ATM adapter card, which supports a multi-mode SONET processing speed per second per second. The maximum transmission unit of the ENI ATM adapter card reaches 9180 bits. Each ENI card has 512KB of motherboard memory. And each ATM virtual circuit connection has up to 32KB connection bandwidth and transmission rate (a total of 64K). This allows 8 switches to connect to the virtual connection at the same time. The CORBA / ATM hardware platform is shown in Figure 14. 4.1.2 Customer / Server Configuration and Baseline Method
Several reference configurations: As shown in Figure 13, our test server includes two service processes in one ORB object adapter. A service process runs with high priority and the other is relatively low. Each thread processes the request for another UltrasParc-2 client thread.
Solaris real-time thread [42] is often used to serve the service process priority. High priority service processes have the highest Solaris real-time process, of course, low priority service processes have the lowest. The service benchmark configuration is performed by a variety of ORBs:
CORBAPLUS: Use the work thread pool system described in Section 3.2.1. Corbaplus, multi-threaded applications, have an event distributor and a work thread pool. The distribution thread gets the request sent and passes them to the working thread. In the simplest configuration, a server application may not choose to create additional threads, depending on the main thread of the processed request.
MINICOOL: Use the leader / follower thread pool system described in Section 3.2.2. The version 4.3 MINICOL allows the application level communication control. Application developers can choose in Thread-Per-Request and Thread-Pool. We use the Thread-Pool communication system because it is more suitable than the THRead-Per-Request more suitable for certain real-time applications. In the Thread-pool communication system, the application first produces a series of threads. Not only that, when the size of the initial thread pool cannot meet the requirements, MiniCool can configure the server program benefit to process the request, which requires dynamic allocation of a maximum number of threads.
MT-ORBIX: Use the thread pool system based on the responsible mode chain of 3.2.3. 2.2 version of MT-ORBIX creates two real-time service processes at the beginning. The high priority thread corresponds to the high priority service, and the low priority thread corresponds to a low priority service. Using the ORBIX thread filtering mechanism, the transmitted request is processed by these threads, as shown in Figure 10. Each priority has its own request queue to avoid priority inversion.
This inversion can be produced from the same queue from the same queue due to high priority and low priority services.
TAO: Use the Reactor-Per-Thread-Priority communication system described in Section 3.2.4. 1.0 version of TAO integrates the Reactor-Per-Thread-Priority communication system using non-multi-channel connections, as shown in Figure 15. In contrast, other three ORB multiplexing technologies use separate connections to receive requests from the client.
Customer Benchmark Configuration: Figure 13 shows how the reference test uses a high priority customer C0 and low priority customer C1 ... CN, high priority customers run real-time OS threads with high priority and call 20 Hz operations, it can be called 20 CORBA two-way requests per second. All low priority customers have the same low priority OS thread and call 10 Hz operations. They call 10 CORBA two-way requests per second. In each request, the customer sends a specific octal CORBA value. The server will return this cube and return to the customer.
When the test program creates a customer thread, they block an obstacle lock, so the customer must wait until the other threads can be created before work.
When all threads are notified that the main thread is ready, the main thread activates all customer threads. These threads are performed in the order determined by a Solaris real-time thread distributor. Each customer calls 4000 CORBA bidirectional threads at a specified rate.
4.2 Performance Test on Solaris
Our experimental baseline uses two strategies: black boxes and white boxes.
Black box benchmark: We calculate the average time of the two-way response of each customer. Not only that, we also calculate the bump time of the two-way operation, which is the standard of two-way response time. High delay and bump are not expected by real-time applications, because they reduce the worst case execution time and reduce CPU utilization. 4.2.1 Partially explained the black box test results. White box test: In order to accurately show the reasons for the priority inversion and non-determination, we use white box benchmarks. These benchmarks use UNIX bundle with quantization tools [43]. These tools track ORB activities and log files to log files, and measure the time spent in each task, as described in Section 4.2.2.
Therefore, the black box and the white box benchmark indicate the lateral delay / jitter caused by CORBA customers, and explains the causes of these results. In general, the results illustrate ORB like ORBIX, CORBAPLUS, and MiniCool is not suitable for performance requirements for real-time systems. Similarly, the result is an example of notification of non-multi-channels used in TAO, and how is the priority-based ORB core system and why is more suitable for real-time systems.
4.2.1 black box results
With the increase of low priority customers, the number of requests for low priority has gradually increased. Ideally, a real-time ORB terminal system should not show inconsistencies when the number of low priority requests is different. Our end-to-end measurement results are shown in Figure 16.
Figure 16 shows how MT-ORBIX and CORBAPLUS grow with the low priority customer growth, which causes the delay time of high priority customer threads. Compared to Tao, the delay time of Mt-Orbix is 7 times that CORBAPLUS is 25 times. Moreover, MiniCool's average delay time is irregular, running 20 low priority customers from 10 秒 delay customers to 25 low priority customers. These uncertainty are not expected by real-time systems.
The low priority customers of MT-ORBIX and Corbaplus and Minicool will also have severe jitter. Compared to the worst case of TAO, the jitter caused by Corbaplus is 300 times, and MT-ORBIX is 25 times, as shown in Figure 17. Similarly, MiniCool's low priority customers show the instability of jitter, which makes it not suitable for real-time systems.
The black box test results of each ORB have a more detailed description
CORBAPLUS Results: Corbaplus causes priority inversion in many cases of Figure 16. After the high delay time of a small number of low priority customers, when the number of customers is 10, the delay time is rapidly decreasing, and it will eventually rise. This unstable manifestation makes it not suitable for certain real-time applications. Section 4.2.2 reveals how such low performance and priority inversion are breed from the communication architecture of Corbaplus. Figure 17 shows Corbaplus generates high priority jitter, especially when the number of low priority customers is 40, 45, 50. Such results indicate that the instability of the application is required to be guaranteed in real time.
MT-ORBIX results: MT-ORBIX increases priority with increased priority customers. When the number of customers exceeds 10, high priority customers are more than low priority customers. This situation does not have benefits for the real-time system of certainty. 4.2.2 The section reveals how these inverses are glow from the MT-ORBIX communication system of the server. Moreover, MT-ORBIX causes the high frequency jitter shown in Fig. 17. This performance is due to the priority inversion in the ORB core, and some of the 4.2.2 are introduced.
Minicool Results: With the increase of low priority customers, high-priority customers have increased, reaching 10 luxuri 20 customers, and then fell to 2.5 seconds 25 customers. This uncertain manifestation is more pronounced at a low priority customer. The delay time of the high priority customers is shorter than the lower priority customers, and the customer's non-linear behavior still makes Minicool are not the best choice for deterministic real-time applications.
Differences between high and low priorities are difficult to predict. For example, the range can be between 0.55 秒 to 10. 4.2.2 Section reveals how this situation is formed in the client mode with server mode. The jitter caused by MiniCool is as very high as shown in Figure 17. This jitter is very similar to the case of Corbaplus ORB, which is because the two spended substantially the same time on the processing of the lock operation. 4.2.2 Some of the locked operation was evaluated.
TAO Results: Figure 16 reveals that the number of high priority customer delay times of TAO increases with a rate of 0.7 Haith with a low priority customer number from 1 to 50. However, the difference between the high and low priority customers is from 0.05 seconds to 0.27 Haith. In contrast, MiniCool increased from 0.55 秒 to 10 seconds, Corbaplus increased from 0.42 秒 to 15th. Moreover, TAO delay time growth is far below MT-ORBIX, Sun Minicool, and Corbaplus. In particular, when 50 low priority customers are CPU utilization and network bandwidth competition, MT-ORBIX's low priority customer delay time is 7 times higher than TAO, and MiniCool is 3 times, Corbaplus is 25 times.
Compared with other ORBs, TAO's high priority customers can always behave better than other low priority customers. This demonstrates the connection and communication system of the TAO ORB core more suitable for maintaining real-time requests. The key difference between TAO and other ORBs is that its Giop protocol processing is performed by a special end-to-end priority real-time thread in a specialized connection. Therefore, TAO shared the smallest ORB terminal resource, which reduces the opportunity of priority inversion and lock operation.
Tao ORB also shows very low jitter, low priority (less than 11 Hazi), high priority (less than 1 Hazi). The stability of the TAO delay time is obviously desirable to predict end-to-end program.
In general, the above black box results describe ORB core communications and connection software systems, which can be derived from deterioration priority inversion and non-determination. TAO can have such low delay time and jitter on the Solaris I / O prove to use standard OO middleware like CORBA to support the feasibility of real-time applications.
4.2.2 White Box Test Results
For white box testing, we used 10 customers as described in the 4.1 part. 9 of them are low priority and the other is high priority. Each customer sends 4000 two-way requests to the server, of course, the server side has 1 low priority service thread and 1 high priority service thread.
We used electronic computing [37] CORBA's experience Description Lock operation Become a real-time system potential priority inversion, uncertainty. Using quantitative and trace tools, we measure the time spent on the ORB in synchronization, I / O, and protocol. Moreover, we calculate a number of processing requests for recording user-level (mutex) and kernel level (LWP mutex). This standard calculates the average number of times each request lock operation. Overall, the kernel-level lock is considered more expensive because they lead to user / kernel mode exchange. The white box test results of our experiment are as follows:
Corbaplus White Box Results: We revealed the Corbaplus's white box analysis results that the two-way connection user-level high frequency is shown in Figure 22. The synchronization problem of the lock operation performs the Corbaplus. Communication and Connecting Architecture shown in Figure 18. The Corbaplus client shows a high user-level synchronization (52%), and the server is (45%), which is due to the operation of the kernel lock. For each CORBA request / response mode, CORBAPLUS's customer ORB performs 199 lock operations, and the server performs 216 user-level lock operations, as shown in FIG. This lock operation is due to dynamic memory allocation, as described in Section 4.4.
Each dynamic allocation causes 2 user-level lock operations, one release and the other. The CORBAPLUS connection and communication system are as follows.
CORBAPLUS Connection System: CORBAPLUS ORB Connection System uses the active connection model described in 3.1.1 and the model shown in Figure 8. This design receives all request multiplexes to the same server through a active connection line, and simplifies the ORB execution process using the unified queue mechanism. CORBAPLUS communication system: CORBAPLUS ORB communication system uses a thread pool. 3.2.1 Partial Description
The system and Figure 8 are described in this mechanism. This system uses a separate I / O thread to receive and read requests from the Socket terminal. This thread will request to insert the queue, of course this queue is served by a worker thread pool.
The Corbaplus connection system and server communication system help reduces simultaneous open connection and simplifies ORB execution. However, the simultaneous request sharing connection causes a high priority inversion, which is because each request sends its own operation leads to content exchange. Moreover, at the client, different priority threads can share the same transmission connection, which may cause priority inversion. For example, a high priority thread may block until a low priority thread ends the request. At the same time, the priority of threads does not necessarily affect the priority of the server-side request, so that additional priority is inverted.
Minicool WhiteBox Results: Our white box analysis of MiniCool reveals that the mutually exclusive synchronous lock will cost a very large percentage of MiniCool ORB processing time. Like CORBAPLUS, the synchronization problem of MiniCool is due to the lock operation of the connection and communication. Lock operation takes 50% in the client, and the server is more than 40%, as shown in Figure 19.
For each ORB request / response mode, MiniCool's customer orb has 94 user-level lock operations, and the server has 231 times, as shown in Figure 22. Like CORBAPLUS, the lock operation is largely breed due to excessive dynamic memory allocation. Each dynamic distribution causes 2 user-level lock operations, one release, and another.
The call caused by the server-side lock operation mechanism for each request (as shown in Figure 23) is often high. In Solaris, this may use the System Range "thread because Minicool threads, which requires kernel level interference to all synchronous operations [44]. The Minicool connection and communication system are shown below: The Minicool ORB connection system uses 3.1.1 The leader / follower model described in 3.1.1. This system allows the leader thread to block SELECT operations on a shared connection. All follower threads wait for one or two conditions of the following: (1) The leader thread can read their reply information and marked the flag. (2) Leaders' county can read his own response and tag another thread into and block Select, so become a new leader.
l MINICOOL communication system: Sun minicool ORB communication system uses the leader / follower thread pool system described in Section 3.2.2. This system is waiting for a separate thread. Whenever a request arrives and confirms, the leader thread (1) marks the follower thread in a pool to wait for the upcoming request (2) and serve it.
The Minicool connection system and server-side communication system help reduces the number of simultaneous development connections and the content exchange when replying to arrive in the FIFO order. Like CORBAPLUS, this design results in high priority inversion. For example, threads of different priority can share the same transmission connection as the client. Therefore, a high-priority thread may block before the low priority thread completes the send request. Moreover, the thread's priority blocking to reach the connection does not necessarily affect the priority of the Response to the server side, which can cause additional priority inversion. MT-ORBIX WhiteBox Results: Figure 20 shows the white box result MT-ORBIX connection system with the client and MT-ORBIX server: Similar to MiniCool, MT-ORBIX uses the leader / follower multi-channel connection system. Although this model minimizes content exchange, it will still cause serious priority inversion. MT-ORBIX Communication System: In our MTORBIX execution baseline, the multi-service thread is created, each of which is a suitable priority service. High priority services have the highest priority thread. A thread filter is installed to handle each request, determine the priority of the request (check the target object), and transmit the request to the thread with the correct priority. The thread filter mechanism is implemented by a high priority real-time thread that minimizes distribution delay.
The thread pool instantiates the MT-ORBIX mechanism shown in Section 3.2.3 and makes it flexible. However, it has been subjected to high frequency priority inverse and synchronous problems. MT-ORBIX provides a filter chain. Therefore, all requests that have been achieved must be processed by the filter before being transmitted to the service thread. Therefore, if a high priority request arrives before a low priority request, it must wait until the low priority request is distributed after the ORB is processed.
Not only that, a filter is just after giop (1), and the adapter (2) determines the target object before being called. This processing process is serialized since the MT-ORBIX ORB core does not know the priority of the request. Therefore, a high priority request to reach later in low priority must wait, knowing that the low priority request is completed by the MT-ORBIX processing.
The MT-ORBIX communication system is mainly responsible for its subsystem priority, as shown in Figure 16. This picture shows how the high priority customer's delay is growing rapidly, from 2 Hazi, rapid growth to 14 秒.
The MT-ORBIX filtering mechanism also led to the growth of synchronous problems. This is because only one filter chain is there, the communication request must be obtained and the lock to be processed by the filter is released. The MT-ORBIX client exhibits 175 user-level lock operations in each request, and the server side exhibits 599, as shown in Figure 22. Moreover, MT-ORBIX demonstrates high-density kernel-level lock operations as shown in FIG.
Tao
White box results:
Figure
twenty one
Distance
Tao
Explains the negligible synchronization problem.
Tao
There is no user-level lock operation at the client, and the same server side will not. This is because
Tao
The core design is determined, it creates a connection for each priority, as shown
12
Indicated. therefore,
Tao
of
ORB
The core does not have user-level and kernel-level lock operations.
TAO connection system: TAO uses a non-multi-diverse connection system, which repeats the connection to the server, as described in Section 3.1.2. One of the connections is established for each priority, thus avoiding the non-deterministic delay in the dynamic connection. Moreover, different priorities have their own connections. This design pattern avoids the request grade priority inversion, which may be arranged in the fifi order and processed by the customer thread with different priorities.
TAO communication system: TAO supports several communication systems, such as [22]. 3.2.4 The Reactor-Per-Thread-Priority system described in the section is used as the reference of this article. In this communication system, a separate thread is created for each priority. Therefore, low priority customers send CORBA requests with low rates than high priority customers. (10Hz vs 20Hz) At the server side, the high priority customer request sent by a high priority real-time thread is processed. Similarly, client requests sent to low priority services are processed by a low priority real-time thread. Due to these 2 service threads shared ORB resources, they separated the Reactors, Acceptors, Object ADAPTERS. Moreover, these two threads are different client connection services, so they exclude priority inversions, such as other ORBs we tested: Our white box test benchmark measures Corbaplus, Mtorbix, MiniCool, and Tao ORB user-level Lock operation (shown in Figure 22) and the kernel stage lock operation (shown in Figure 23). The user-level lock operation is a typical use to protect a share of resources. An ordinary example is to use global C operators New and Delete to dynamically memory allocation. These operators allocate memory from the global management stack in each process.
User-level lock operation is more expensive, because they need to switch between user-level and kernels. Banquet and mutual exclusion operations exhibit in the white box test results evaluated by the ORB kernel lock operation.
Figures 22 and 23 illustrate other three ORBs, but TAO does not cause lock operation of user-level and kernel level. We can set TAO so that it will not allow ORB resources to be shared by its thread. For example, it uses a repeated allocated real-time stack buffer to reduce dynamic memory allocation, and its related locked operations. Each buffer is divided to support a wide range of requests.
4.3 CHORUS CLASSIX performance results:
4.2 Section The performance result is obtained from Solaris 2.5.1, which provides real-time timing but does not provide real-time I / 0 [42]. Therefore, Solaris cannot guarantee the availability of resources like I / O buffers and network bandwidth [22]. Moreover, the timing of the Solarisi / O subsystem is not integrated with other resources. This allows the application to ensure that QoS demand is satisfied. The QoS mechanism provided by the real-time operating system includes real-time timing classes. They guarantee QoS, and real-time I / O. Chorus Classix is a real-time OS that can be configured in an embedded system or on a distributed POSIX-Compliant platform [45]. Classix provides a real-time timing control to support several timing algorithms, including FIFO-based timing algorithms. It supports real-time applications and integrated applications.
The IPC mechanism is used on ON Classix, Chorus IPC, providing an effective, local message-based communication, which is between a single motherboard and other connection motherboards. Moreover, Classix has a TCP / IP protocol stack that can be obtained by the Socket API to allow communication with other OS platforms over the network.
In order to determine the influence of real-time OS in ORB performance, this subclass divided the black box result of Tao and using Classix's MiniCool.
4.3.1 Hardware Configuration
The following experiments use 2 MVME177 VMebus single-motherboard computers. Each MVME177 includes one
A 60MHz MC68060 processor and a 64M RAM. MVME177 motherboard is hanging in one
MVME954A, 6-SLOT, 32-bit, VME-plate. Moreover, each MVME177 module has 82596CA
Etherus receptacle interface.
4.3.2 Software Configuration
Our experiments are executed on a computer running the Classix3.1 version. The ORB benchmark is MiniCool 4.3 and TAO1.0. Customer / Server is configured locally (1), and the customer is on the same motherboard. The client / server reference is configured to perform in the same manner on Solaris 2.5.1, as described in Section 4.1.2. MINICOOL is configured to send messages on the motherboard, or using a Chorus IPC communication tool, which is more efficient than the chorus TCP / IP protocol stack. Moreover, we guide the Betmark of MiniCool and Tao to use the TCP protocol. In general, MiniCool, using Chorus IPC as a transmission mechanism exhibits more excellent predictability. 4.3.3 Black box test results:
We calculate the average two-way response time of various customers. Moreover, we calculate the jitter time of the two-way operation. High delay and jitter time is not expected by real-time applications, because they can exacerbate the worst performing time and reduce CPU utilization.
Minicool, using Chorus IPC: With the increase in the number of low priority customers, the number of remote high priority customers has also grown accordingly. When reaching 34 秒, a straight-line growth trend, if the customer is on a different processor board, as shown in Figure 24.
Once the customer is configured with the server, more stable performance is exhibited at the high and low priority customers. The delay time has increased from 2.5 narconds to 12.5. The same high and low priority results in approximately the same average delay time.
In all cases, high-priority customers have less delayed time than low priority customers, so there is no serious priority inversion, which is exactly what is expected to be in real time. However, high priority customers will still have delay time and are remote and local configurations.
,
