Data Initialization Schema

Top  Previous  Next

With the advent of the new threading model in this release, it is important to understand how threaded and non-threaded data elements are initialized, and in what specific order.

 

Prior to this release, data elements in respective modules were initialized in the following schema.

- non-threaded data of module1

- non-threaded data of module2

- ...

- non-threaded data of modulen

 

- threaded data of module1

- threaded data of module2

- ...

- threaded data of modulen

 

With the current release, the data initialization schema is as follows:

 

- non-threaded data of module1

- threaded data of module1

- non-threaded data of module2

- threaded data of module2

- ...

- non-threaded data of modulen

- threaded data of modulen

 

This means that a problem could arise if you attempt to access a threaded file from the constructor of a non-threaded class module. The initialization sequence for objects has changed so that non-threaded objects within a module are initialized before threaded ones.

 

There are two solutions to overcome this issue.

 

1. Make the threaded file non-threaded, or:

 

2. Move the definition for the class into a different module and set its initialization priority (init_priority) to a number less than the default initialization of 5.

 

PRAGMA ('define(init_priority=>4)') !add to the top of the module

 

 

The compiler initialization sequence of data, and calls to constructors is as follows:

 

1) Patching for threaded data in module-1

2) Patching of non-threaded data in module-1

3) Constructors of non-threaded data in module-1

4) Constructors of threaded data in module-1

 

.... repeat (1)-(4) for additional modules.

 

Steps (1) and (2) can be required if FILEs or VIEWs use strings that are imported from external

DLLs.