Thread Safety

OpenAccess supports thread safety for two basic use models: multiple reader threads operating on one or more databases and multiple writer threads operating on a single thread per database basis. OpenAccess ensures database access thread safety under the defined multi-thread usage models, it will not create threads or use them internally.

Applications can turn on thread safety and locking within the session if they have met certain prerequisites and by calling oaSession::setThreadUseModel with one of the following thread use model enums.

oaThreadUseModelEnum Prerequisites? Locking? Description

oacSingleThreadUseModel None No The application intends to interact with OpenAccess using a single thread. This is the default.

oacMultipleReadersThreadUseModel Yes Yes The application intends to use multiple read-only threads to access one or more OpenAccess databases concurrently.

oacMultipleWritersThreadUseModel Yes Yes The application intends to use multiple read-write threads to edit a single OpenAccess database per thread.

oaThreadUseModelEnum	Prerequisites?	Locking?	Description
oacSingleThreadUseModel	None	No	The application intends to interact with OpenAccess using a single thread. This is the default.
oacMultipleReadersThreadUseModel	Yes	Yes	The application intends to use multiple read-only threads to access one or more OpenAccess databases concurrently.
oacMultipleWritersThreadUseModel	Yes	Yes	The application intends to use multiple read-write threads to edit a single OpenAccess database per thread.

Single Thread Use Model

This is the default level of thread safety supported by OpenAccess. The application will use a single thread in all of its interactions with OpenAccess. There are no prerequisites for operating in this use model. There is no performance or capacity overhead due to thread-safety protection when operating under this use model.

Multiple Readers Thread Use Model

The application intends to use multiple read-only threads to access data in one or more OpenAccess databases. A "read-only" thread is a thread that does not change the state of any database. The application will not open new databases, or modify the session in any way (for example, by creating appDefs, constraintDefs or other defs) either. On entering this mode, OpenAccess will precondition certain internal data structures and will enable internal locking on shared resources. In particular, all designs that were open in partial read will be completely read into memory. This can cause the size of the process to grow significantly. Additionally, there is a certain amount of overhead associated with resource locking. A single thread operating in the Multiple Readers Thread Use Model will not run as fast as a single thread operating under the Single Thread Use Model. However this overhead is small and properly written applications should scale as expected with the number of threads and the number of available CPUs.

Application Responsibilities

These are the prerequisites that must be satisfied by the application before entering the Multiple Readers Thread Use Model.

Initialize all the oaObsevers used by the application.
Open all the libraries, designs, techs and other databases that any of the threads will use. For example, a top oaDesign and all the designs in its hierarchy.
Initialize region query data structures if any of the reader threads will do a region query.
Bind oaInstHeaders and oaViaHeaders to their masters, if any of the reader threads will descend into the masters during the multi-threaded session. The binding of oaTech and oaDesign is handled automatically by OpenAccess core.
Evaluate and bind all Pcell subMasters that will be needed by any of the reader threads. In particular, threads may not create new instances or change Pcell parameters.
If any of the reader threads will traverse the occurrence hierarchy, the application must expand the occurrence hierarchy of each open design to the frontier that will be used.
If any of the reader threads will access parasitic networks, the application must either pre-load those parasitic networks (which could be a capacity concern), or explicitly synchronize all calls to oaParasiticNetwork::load() and unload() at the application level.
If any of the reader threads will access oaOccShape objects, which are dynamically generated, the application should either pre-generate all the occShape objects, or explicitly synchronize the queries which generate or release the occShapes at the application level.

In debuggable builds, OpenAccess will assert if any databases are opened, closed, purged, or bound while in the Multiple Readers Thread Use Model. In optimized builds there are no protections. If applications do not adhere to the responsibilities and restrictions imposed by the use model, the results are undefined.

Multiple Writers Thread Use Model

The application intends to use multiple writer threads on a single writer thread per database basis. A "writer thread" is a thread that creates or edits OpenAccess data in a single database but which does not modify the state of the OpenAccess session or modify the state of other databases either directly or indirectly. In particular, writer threads must not open new databases, trigger binding between databases or add new objects to the technology database. Changes made by a writer thread must be completely isolated to the design database to which it is assigned. As with the Multiple Readers Thread Use Model, upon entering this mode all designs that were open in partial read will be completely read into memory and resource locking will be enabled.

Application Responsibilities

These are the prerequisites that must be satisfied by the application before entering the Multiple Writers Thread Use Model. The application responsibilities for the Multiple Writers Thread Use Model are the same as the application responsibilities for the Multiple Readers Thread Use Model with the additional constraints mentioned above.

Initialize all the oaObsevers used by the application.
Open all the libraries, designs, techs and other databases that any of the threads will use. For example, a top oaDesign and all the designs in its hierarchy.
Initialize region query data structures if any of the threads will do a region query.
Bind oaInstHeaders and oaViaHeaders to their masters, if any of the threads will descend into the masters during the multi-threaded session. The binding of oaTech and oaDesign is handled automatically by OpenAccess core.
Evaluate and bind all Pcell subMasters that will be needed by any of the threads. In particular, threads may not create new instances or change Pcell parameters.
If any of the threads will traverse the occurrence hierarchy, the application must expand the occurrence hierarchy of each open design to the frontier that will be used.
If any of the threads will access or edit parasitic networks, the application must either pre-load those parasitic networks (which could be a capacity concern), or explicitly synchronize all calls to oaParasiticNetwork::load() and unload() at the application level.
If any of the threads will access or edit oaOccShape objects, which are dynamically generated, the application should either pre-generate all the occShape objects, or explicitly synchronize the queries which generate or release the occShapes at the application level.

While in the Multiple Writers Thread Use Model, writer threads must adhere to the following constraints:

Changes (direct and indirect) made by a writer thread must be completely isolated to the design database to which it is assigned.
Writer threads must not open new designs.
Writer threads must not trigger binding between design or technology databases.
Writer threads must not create new Pcell instances.
Writer threads must not add, delete or change parameters of a Pcell instance or Pcell superMaster.
Writer threads must not define new Pcell superMasters.
Writer threads must not add new objects to technology databases.
Writer threads must not set or unset technology database references.
Writer threads must not create new appDefs, appObjectDefs, constraintParamDefs, constraintDefs, derivedLayerParamDefs, derivedLayerDefs, groupDefs or constraintGroupDefs.

In debuggable builds, OpenAccess will assert if any databases are opened, closed, purged, or bound while in the Multiple Writers Thread Use Model. In optimized builds there are no protections. If applications do not adhere to the responsibilities and restrictions imposed by the use model, the results are undefined.

Changing Use Models

Applications can freely switch from multi-threaded use models to single threaded and back again in the same session. However, OpenAccess will not revert any data preconditioning that may have been done to support a multi-threaded use model when switching back to single threaded.

Return to top of page

Return to Programmers Guide topics