2.5 Concurrency Modes

A device model can run in one of three concurrency modes. The modes are as follows:

Sim_Concurrency_Mode_Serialized

The model can assume Cell Context.

The model is put in the cell thread domain.

The device may interact with all objects in the cell without having to acquire any thread domains or take threading into account.

Objects in the same cell, including objects belonging in other thread domains, always have a stable state when queried.

The direct memory subsystem ensures that there is no observable concurrency on memory pages held by the model.

Sim_Concurrency_Mode_Serialized_Memory

The model runs in Threaded Context.

The model is put in a separate thread domain.

The model is required to handle locking explicitly for both incoming and outgoing interface calls.

Whenever the model crosses a thread domain boundary, or enters Cell Context, all devices in the cell can potentially undergo state transitions.

The direct memory subsystem ensures that there is no observable concurrency on memory pages held by the model.

Sim_Concurrency_Mode_Full

The model runs in Threaded Context.

The model is put in a separate thread domain.

The model is required to handle locking explicitly for both incoming and outgoing interface calls.

Whenever the model crosses a thread domain boundary, or enters Cell Context, all devices in the cell can potentially undergo state transitions.

The model cannot assume that pages granted through the direct-memory subsystem are not accessed concurrently from a different thread, unless exclusive access have been requested explicitly.

2.5.1 Mode Selection

A model advertises its supported concurrency modes through the concurrency_mode interface. If the interface is omitted, and the object is not grouped with an object implementing the concurrency_mode interface (see the next section), then the model is assumed to only support Sim_Concurrency_Mode_Serialized.

If the model supports multiple modes, the interface is also used by Simics to select the concurrency mode the model should use. The mode is derived from the simulation mode set through the set-threading-mode command.

Device models normally run in the serialized concurrency mode, whereas CPU models preferably should support all the modes.

2.5.2 Thread Domain Groups

In many cases, there are multiple objects that should reside in the same thread domain. Examples include:

• a CPU and an object representing its TLB
• a CPU and a CPU-specific timer
• two hyper threads which share a substantial amount of registers and whose implementation is not thread safe

1. constraints that are used in all concurrency modes
2. constraints that are only used in the serialized memory mode.

A port object is always placed in the same thread domain as its parent, unless it implements the concurrency_mode interface or is grouped explicitly with such an object.

For CPU models, the following is recommended:

Sim_Concurrency_Mode_Serialized_Memory

Tightly connected CPUs are grouped together.

In this context, tightly connected really means CPUs that run the same OS instance. CPUs which run distinct OS instances, but share memory, or devices, through some fabric, do not need to be placed in the same group.

Sim_Concurrency_Mode_Full

All CPU cores are placed in separate thread domains.

The above allows groups of tightly coupled CPUs to be simulated in parallel when the simulation is configured to use subsystem threading, while allowing all the CPUs to run in parallel in multicore mode.