GRATgen: $title

GRATgen

Object Initialization and Lifetime

# Object Initialization and Lifetime

We describe the object initializations during checking. TODO: The initialization seems to complicated, and could definitely be improved.

1. Initialized first is a single instance of the Global_Data class (glb). The lifetime of this data is split into two phases: During parsing and after parsing.
2. During parsing, the clause database grows, such that pointers into the clause database may be invalidated. In this phase, relative positions (pos_t) are used to reference to items in the clause database.
3. Once parsing has completed, the size of the clause database is fixed, and pointers to the first literal of a clause can be used. (see Internal storage of clauses for a description how clauses are stored). The phase transition is currently done by Parser calling the private Global_Data::init_after_parsing(). The current phase can be queried by Global_Data::is_after_parsing().
4. Next, an object of type Synch_Data is initialized. It must only be initialized when glb is after parsing.
5. Next, a main Verifier is constructed, and the Synch_Data object is declared to it via Verifier::init_after_parsing().
6. Using the main verifier, the forward pass of the checker is run.
7. After the forward pass has completed with a non-trivial conflict, the conflict clause and the forward trail are declared to the glb object (Global_Data::init_after_fwd()).
8. Then, the main verifier is copied for each additional checker thread, and the backward passes are run in parallel. Copying a Verifier also creates a new instance of the clause database (Verifier::Verifier(Verifier const &)).
9. After all backward checkers have completed, the trail marking information for the main trail, which was collected by each backwards pass privately, is joined. (Global_Data.join_vmarked())
10. Finally, the GRAT certificate is written out (VController::dump_proof())