| Navigation: Advanced Topics > Thread Model Documentation >====== Data Initialization Schema ====== |    |
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.