STRIDE 3.0.01xx: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
Line 7: Line 7:


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


===Runtime Logging (Optional)===
===Runtime Logging (Optional)===

Revision as of 18:31, 22 May 2008

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

Please review this information before upgrading from an earlier version.

What's New

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

Support for Multi-Process Target

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

Runtime Logging (Optional)

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

Change Details

Shared Memory

To support multi-process target, shared memory support for pool and dynamic memory has been implemented in Runtime. Runtime makes PAL calls to acquire shared memory and manages the memory according to runtime configurations set by user.

Protection using Mutex

Runtime now uses named mutex objects to protect shared resources between multiple processors and multiple threads. Runtime makes PAL calls to obtain and control mutex objects.

PAL

New Routines

  • Shared Memory Management

Recommended approach is to use Memory-Mapped Files to implement shared memory.

palOpenSharedMem - Open/Create shared memory segment 
palCloseSharedMem - Close shared 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

Removed / Old Routines

palProtect
palUnprotect

Runtime

  • STRIDE Host Release 2.1.0301 is compatible with the Runtime versions 3.0.
  • To support multi-process target, significant changes have been made to runtime.
  • A new public routine, srUninit(), has been added to sr.h and srapi.c.
  • 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

You may reference Linux implementation of PAL, which has been updated to support shared memory.

  • Implement new shared memory routines using memory-mapped files.
  • Runtime now manages shared dynamic pool memory. Update palMemAlloc() to simply call _srMem_Allocate() and palMemFree() to simply call _srMem_Free() for the shared memory case.
  • Implement new mutex routines to handle any named mutex objects. It is recommended to implement a separate code for shared memory case.
  • Remove old routines palProtect() and palUnprotect().
  • Implement new routines palGetThreadId() and palGetProcessId().
  • Implement new routine palSleep().

Runtime

Host-based TargetApps using s2shostapptrt library

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