Collapse all Symbian^3 Product Developer Library

Interrupt Handling

Describes how interrupts are handled in the SMP environment.

An interrupt is a signal from a hardware device or from an executable which causes a CPU to suspend normal execution, enter the interrupt handling state and jump to an interrupt handler. An interrupt handler, or ISR (interrupt service routine), schedules a DFC (delayed function call) on a DFC queue.

SMP-Safe Interrupt Handling

Interrupt handlers are used to implement the functionality of device drivers.

When a DFC executes on a unicore system, it disables interrupts to avoid clashing with its own ISR.

On a multicore system this is not sufficient to maintain data integrity. To maintain data integrity on an SMP system the code must:

acquire a spin lock on any data to be written, to block other cores from accessing the data.
Interrupts must be disabled, as on unicore, before the spin lock is acquired.

Although these are conceptually two separate tasks, you use the spin lock API TSpinLock in nkern.h to perform both tasks at the same time.

The following macros provide SMP-safe interrupt handling in most situations.

If code using these macros is executed on a unicore system, they will disable interrupts in the normal way.

There are several other macros that can be used in the non standard situations or when you require greater control over the interaction of interrupt disabling and spin locks.

__SPIN_LOCK_IRQSAVE(lock)

Standard SMP-safe macro
__SPIN_UNLOCK_IRQRESTORE(lock,irq)

Standard SMP-safe macro
__SPIN_FLASH_IRQRESTORE(lock,irq)
__SPIN_LOCK(lock) __SPIN_UNLOCK(lock)
__SPIN_FLASH_PREEMPT(lock)
__SPIN_LOCK_IRQ(lock)
__SPIN_UNLOCK_IRQ(lock)
__SPIN_FLASH_IRQ(lock)

Note:

To ensure SMP Safety in Symbian^3, the kernel ensures that device driver, ISR and DFC are all tied to the same CPU. CPU0 has been stipulated for this purpose.

Using a spin lock

In the following example, a spin lock protects memory being written by DfcFun() on CPU0 from corruption by ISRFun() running on a different core.

This code runs on CPU0:

void DfcFun(TAny* aPtr)
	{
	…
   irq = __SPIN_LOCK_IRQSAVE(iLock);
   iState = EProcessed;
   __SPIN_UNLOCK_IRQRESTORE(iLock,irq);

	...
	}

This code runs on a different core:

void ISRFun(TAny* aPtr)
	{
   __SPIN_LOCK(iLock);	
	iState = EProcessing;
	__SPIN_UNLOCK(iLock);
	}

Making your device driver SMP safe

Once a device driver has been migrated to be SMP Safe using the advice above, the mmp file of each driver's binaries must be updated with the keyword SMPSAFE.

This indicates to the scheduler that the kernel side threads and associated interrupts can be can be run and executed according to the kernel SMP policies.

SMP Safe

The SMPSAFE keyword should only be used if the code is proven to be SMP-Safe.

Impact of using the SMPSAFE keyword:

If your code is proven to be SMP-Safe you can identify it is such by inserting the SMPSAFE keyword into your mmp file. The kernel will mark your application or service as SMP-safe and use whatever processors are available according to the policies of that baseport.
If the code is not SMP-Safe do not use the keyword. The kernel will run your code using the behaviours defined by the appropriate compatibility mode, ensuring that all threads are run on a single CPU.

There are two SMP compatibility modes: basic and enhanced.

In basic mode all threads in unsafe processes are set to CPU0. There is no chance these threads will run concurrently and therefore they are executed in priority order, as on a single processor system.
In enhanced mode all the threads of a process are tied together in a thread group. Only one thread of a thread group can be run at any time, meaning they are executed in priority order. The benefit of the enhanced mode is that the entire thread group may be moved from one CPU to another as system resources and kernel policy demands. The default SMP compatibility mode is enhanced.

The decision to use basic or enhanced SMP-Safe compatibility mode is made at design time and assigned to the kernel iby/oby file as part of the baseport. Once set this can not be changed. This is an either or choice and therefore mutually exclusive.

Parent topic: SMP Concepts

Related concepts

SMP Overview

Spin Locks