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.