STRIDE 3.0.01xx

Release Notes

This page documents the changes in STRIDE version 2.1.0301 (code name StoneSteps).

Please review this information before upgrading from an earlier version.

What's New

Build Tools

A set of new command line build tools has been implemented:

• Stride compiler
• Stride database binder
• Stride instrumantation generator

These utilities has been ported for Windows and Linux. Using them would allow seamless integration with "make" like build environment.

Runtime/PAL

Based on customer requirements, in this release we have made significant changes to STRIDE Runtime and PAL.

Multi-Process Targets

New routines and support have been added to Runtime and PAL to support multi-process target. Changes include implementation of memory management and shared memory, protecting using named Mutex objects, synchronization of multiple processors and multiple threads, and usage of current process and thread IDs.

Logging (Optional)

Runtime and PAL use a logging routine that can optionally be implemented in PAL.

Change Details

PAL

Memory Management

To support multi-process target, memory management support for dynamic, configurable, and internal static memory has been implemented in Runtime. Runtime makes PAL calls to acquire memory segments and manages the memory according to runtime configurations set by user. In case of multi-process target is enabled, these memory will be shared among multiple applications, and PAL should implement shared memory.

Protection using Mutex

Runtime now uses named mutex objects to protect critical data from multiple and simultaneous accesses by multiple threads and, in case of multi-process target is enabled, by multiple applications. Runtime makes PAL calls to obtain and control mutex objects.

New Routines

• Memory Management

In case of multi-process target, recommended approach is to use Memory-Mapped Files to implement memory segments.

palMemSegmentOpen - Open/create memory segment 
palMemSegmentClose - Close memory segment

• Named Mutexes

palMutexInit - Initialize a mutex object
palMutexDestroy - Destroy a mutex object
palMutexLock - Lock a mutex object
palMutexUnlock - Unlock a mutex object

• Task Synchronization

palGetThreadId - Get current thread Id
palGetProcessId - Get current process Id
palSleep - Suspend the execution of the current thread

• Logging

This is optional.

palLog - Logging utility

Updated Routines

Function signatures of palMemAlloc() & palMemFree() have been updated.

palMemAlloc - now returns a void pointer
palMemFree - now takes in a void pointer as input

Removed / Old Routines

palProtect
palUnprotect
palCriticalErr

Removed Module

S2Mem - Memory module provided as part of PAL has been removed. If native OS does not support dynamic memory, Runtime's memory management module srMem can be used instead of S2Mem.

Runtime

• STRIDE Host Release 2.1.0301 is compatible with the Runtime Version 3.00.
• To support multi-process target, significant changes have been made to runtime.
• A new public routine, srUninit(), has been added to sr.h & srapi.c.
• A new module, srMem, for Memory Management has been added. Its new routines, _srMem_Allocate() & _srMem_Free(), will be used in PAL's palMemAlloc() & palMemFree() in case of multi-process target is enabled.
• Calls to palProtect() & palUnprotect() have been replaced by new routines _srProtect() & _srUnprotect(), in which the implementation uses its own mutex object that calls PAL's mutex routines.

• The following Runtime files have been modified:

sr.h
srapi.c
srconn.c
srconn.h
srib.c
srib.h
sribtr.c
sribtr.h
srmsgptr.c
srmsgptr.h
srmsgque.c
srmsgque.h
srmsgrt.c
srmsgrt.h
srmsgsub.c
srmsgsub.h
srstid.c
srstid.h
srsuid.c
srsuid.h
srtime.c
srtime.h

• The following Runtime files have been added:

srmem.c
srmem.h

Migration to 2.1.0301

Recommended steps for migration from a previous version:

PAL

Please refer to Platform Abstraction Layer (PAL) Specification for detailed information on new APIs. You may also refer to Linux implementation of PAL, which has been updated with new routines.

• Implement new shared memory routines, palMemSegmentOpen() & palMemSegmentClose(). In case of multi-process target, these routines should implement shared memory using memory-mapped files.

• Runtime now can manage dynamic, configurable, and internal static memory. In case of multi-process target, update palMemAlloc() to simply call _srMem_Allocate() and palMemFree() to simply call _srMem_Free(). In case of single-process target, you can simply allocate dynamic memory according to your Operating System. If you are upgrading, you can simply leave the current implementation as it is.

• Implement new mutex routines, palMutexInit(), palMutexDestroy(), palMutexLock() & palMutexUnlock, to handle any named mutex objects. It is recommended to implement a separate code for shared memory case if it is necessary.

• Remove old routines palProtect(), palUnprotect() and palCriticalErr().

• Implement new routines palGetThreadId() and palGetProcessId().

• Implement new routine palSleep().

• Update synchronization routines, palCreateNID(), palDeleteNID(), palWait() & palNotify(), to support sharing of the synchronization objects among multiple processors if shared memory management is enabled.

• If your PAL was using S2Mem routines for dynamic memory, you should use new Runtime module srMem. Update palMemAlloc() to call _srMem_Allocate() and palMemFree() to call _srMem_Free().

• Optionally, implement new routine palLog() as a logging utility for PAL and Runtime.

Runtime

• Edit srcfg.h file to configure the new memory management (srCFG_MEMORY_MANAGEMENT) and multi-process target (srCFG_MULTI_PROC_TARGET) settings. By default, memory management and multi-process target are disabled. If you enable multi-process target you also need to enable memory management and configure the sizes and the maximum number of memory blocks. New Runtime module srMem uses these configurations to allocate and manage memory segments.

Host Apps using Target Runtime lib s2shostapptrt

• A new routine, HostAppSetMaster(), has been added to s2shostapptrt library. This routine needs to be called from the application that should be starting the runtime thread, srThread, before calling HostAppRun(). Usually within a multi-process target, the master process or the daemon calls this routine.