A method for effective recovery of C + + reference counting by intelligent pointer

Whether reference count pointers are effectively recycled is critical to recovery of data after a system shutdown unexpectedly, and the key is to avoid object duplication.

How to recover a long-running, system-level daemon or service from a catastrophic failure has become an important consideration in today's software design process. When these software are compiled by the C + + language and use reference-counting smart pointers, efficient recovery of smart pointers is critical to whether the system has a scalable level of resilience, or even to continue the unfinished operation correctly.

In this article, we describe a method that can be recovered from software recovery after shutdown effectively recycling reference count pointers, and this method is also very efficient in terms of memory footprint, the key to avoiding object duplication is that object replication is typically produced by the traditional technique of serialization and drag of pointer references in C + +. When drag from an archive file, this method uses tags (tag) to uniquely identify the pointer object and save the pointer reference by an object cache when the system recovers.

In this paper, an event-based commercial real-time job scheduling system is presented, which is usually used by large market consulting firms, which handle countless computing tasks on a cluster workstation every day.

Why do many C + + software projects use automatic memory management technology because it has the following benefits:

² code Security. Avoids the risk of releasing an object too early.

² Code Correctness. Avoids the risk of forgetting to free unused memory.

² Code modularity. The code does not need to be dotted with program-independent bookkeeping code.

² simplicity of Programming. You can now assume an infinite memory calculation pattern.

² High efficiency of programming. Programmers are no longer worried about memory management issues.

Reference counting smart pointers, sometimes referred to as "counting body terms", are a lifetime-managed object that has an internal counter for the number of references to it. When the internal reference count is zero, these objects automatically destroy themselves, which is a very useful technique that has been used in many C + + SOFTWARE PRODUCT projects because it is straightforward and does not require any extensions to the language or compiler.

Reference counting smart pointers can be further defined as integral or detached, and the All-in-one smart pointer puts the reference count within itself, while the detached smart pointer places the reference count outside the object. In this article, a discrete smart pointer scheme is used, which requires overloading the-> or the * operator in the smart pointer template object before accessing the actual object pointer, which is, in essence, a special case of the proxy design pattern.

For now, there is no scenario that describes how to recover a smart pointer in a way that efficiently uses memory. The traditional C + + object serial and drag method can cause memory inefficiency because when a drag object encounters a reference to it, it always creates a new object, and in the worst case, This pushes the memory consumption of a restored daemon to an unacceptably high level, leaving it unable to continue running.

The problem arises

The traditional object's serial and drag-line scheme can also realize the intelligent pointer, but it is less efficient in memory. In these traditional scenarios, when an object is serialized, the member pointer within the object is referenced, and its contents are "serially" in the archive file with the object. The problem with this approach is that when drag is done, the member pointers are constructed again and are the same for each recovered object.

The following is explained by the event-based job scheduling system, which is defined in the Cjobdef object, which contains the static properties of the job, such as the commands it executes, the working directory, and the user ID of the job execution. The run instance of the job definition is wrapped in a Cjobinst object that contains some properties related to the instance, such as its process ID, execution parameters, and run history. At the class level, each Cjobinst object contains a member that references the original Cjobdef object that triggered the job instance.

Figure 1 is the system before the software stops running, and multiple instances of the Run-time Cjobinst object may be referenced to the same Cjobdef object. After software stops and restores, the traditional serialized object recovery method causes a Cjobdef object to be created for each running Cjobinst object, as shown in Figure 2.

Figure 1: The object graph before recovery

Figure 2: Object graph after memory low-efficiency recovery