From RTSC-Pedia

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC

Extending xdc.runtime Gates

How to provide mutual exclusion gates

Introduction

The xdc.runtime package manages a few global data structures that must be protected in multi-threaded environments. Since the xdc.runtime package requires a mechanism to protect concurrent access to data and this is a common requirement for multi-threaded applications, the xdc.runtime package

• provides a module, Gate, that enables applications to easily serialize access to shared data structures, and
• defines an interface, IGateProvider, that enables you to "extend" or port the xdc.runtime package to support any multi-threaded environment.

In the sections below, we show how to port the xdc.runtime package to virtually any multi-threaded environment. This not only enables use of the xdc.runtime modules in a multi-threaded environment, but also enables the use of "thread-aware" modules that rely exclusively on the xdc.runtime services for synchronization services to also be used in such an environment.

Overview

Concurrency support is provided by the xdc.runtime package via "gates", simple mutexes that can be recursively acquired by the same thread.

With the exception of "lock free" data structures, mutexes are necessary to protect shared data structures. But not every application allows multiple threads to call every function in a system and, as a result, some applications don't require protection for all modules that manage sharable data; just because data managed by a module is sharable does not mean that it's shared in every application. Of course a module producer can't know whether their module(s) will be concurrently accessed, so they must implement their module assuming that it will be. The consequence is that single threaded applications, and even well structured multi-threaded applications, incur unnecessary overhead of locking and unlocking mutexes around data that are never accessed concurrently. This performance verses multi-threading support tradeoff can be resolved if the overhead of the mutex can be made very low.

Short duration locks can often be implemented efficiently using platform-specific services; e.g., locks on uni-processors systems are very efficiently implemented by disabling all interrupts on entry and restoring interrupt state after the operation is complete. Some processors, such as TI's C6000 CPUs can disable and restore interrupts around short sections with just 1 cycle of overhead. Because of the low overhead of these mechanisms, the unnecessary overhead incurred by some applications can be largely ignored. However, it's important to keep in mind that execution time overhead is not the only performance metric for real-time systems. Response time latencies are also critically important and a module that disables interrupts for even a micro-second may be unacceptable.

Depending on the operation required on shared data, it may be necessary to allow a thread to be preempted while it holds one or more locks. But locks with this property generally require much greater overhead and are operating system specific. So we're back to the problem of imposing unnecessary overhead on some users and the module producer must reimplement the module for every operating system used by her customers.

RTSC enables module providers to write their modules in such a way that they

• are 100% operating system independent,
• enable integrators to eliminate unnecessary execution time overhead, and
• can be delivered as binary libraries; i.e., they don't require re-compilation by the end user.

In short, module providers can write their code once for all application environments and system integrators can eliminate unnecessary synchronization overhead on a per module basis.

Architecture

RTSC modules that manage data that may be concurrently accessed must be designed with synchronization overhead and scheduling latency considerations in mind. The System gate is used to protect very short duration operations (via Gate_enterSystem() and Gate_leaveSystem()). If a module requires a longer duration gate, it declares that it is "gated" via the @Gated attribute in the module's specification. In so doing, the system integrator has the opportunity to assign an appropriate gate to the module. If a gated module will be concurrently accessed you must assign an appropriate IGateProvider instance to the module. If, on the other hand, you know that a gated module is never accessed concurrently, you can assign an instance of the GateNull module to the module's .common$gate configuration parameter and avoid the time and space overhead associated with a non-trivial gate.

The xdc.runtime.System module is gated and the xdc.runtime.Gate module allows other modules to use the "System gate"; i.e., the gate associated with the system module.

Configuration

If the xdc.runtime package is used in a multi-threaded environment you must configure the xdc.runtime.System module's gate with a gate that only allows one thread at a time to operate inside the gate. Some Real-Time Operating Systems (RTOS), such as DSP/BIOS, automatically configure the System module's gate to allow any thread (even ISRs) to use the xdc.runtime. If you are not using such an RTOS, you'll have to find (or create) a module that implements the IGateProvider interface, and use this module to create an appropriate gate for the System module.

var Lock = xdc.useModule("examples.runtime.gates.Lock");
System.common$.gate = Lock.create();

Examples

In the table below, we list examples that illustrate the key requirements of gate providers.

See also

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC