Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

Using Signals
OSS signal functions can be used with TNS/R and TNS/E native Guardian processes but not with
TNS processes. Refer to the Open System Services Programmer’s Guide for more information.
Using Shared Memory
Shared memory segments enable processes to communicate directly with each other by sharing
portions of each other’s address space in a single processor. Shared memory does not simply
provide common access to data, it provides the fastest possible communication between processes.
With one memory write operation, a process can pass information to as many processes as have
the memory region shared. The shared memory segments created and managed by the OSS
shm*() functions are distinct from segments created by the Guardian SEGMENT_ALLOCATE_
and related procedure calls. Both kinds of segments can be created and shared, but one kind
cannot be shared with the other.
Both Guardian and OSS processes can call SEGMENT_ALLOCATE_ and related Guardian
procedure calls: they can share segments as described for SEGMENT_ALLOCATE_.
On servers running J06.12 or later J-series RVUs or H06.23 or later H-series RVUs, both Guardian
processes and OSS processes can call the OSS shared memory functions, which are shmat(),
shmctl(), shmdt(), and shmget(). They can share segments as described for shmget().
On servers running J06.11 or earlier J-series RVUs, H06.22 or earlier H-series RVUs, or G-series
RVUs, only OSS processes can call shmget() and related functions; Guardian process calls to
these functions fail and errno is set to the value of [ENOTOSS].
Memory segments can be shared with a process’s child processes by offering communication
through a “thick pipe” between the parent and child process. Attached segments are propagated
during a fork() function and detached with the exec or tdm_spawn sets of functions. Memory
segments are not propagated to a child process after any of the exec, tdm_exec, or tdm_spawn
sets of functions, or when the child process resides in a different processor from the parent.
If your programs use shared memory, use semaphores to synchronize access. (Semaphore
synchronization is done frequently in environments based on UNIX.) Semaphores are described
under “Using Semaphores” (page 93).
TNS and native processes can share segments in 32-bit address space, using
SEGMENT_ALLOCATE_ with either the share-by-PIN or share-by-filename method. TNS/E 32-bit
or 64-bit native processes can also use SEGMENT_ALLOCATE64_ to share 32-bit segments. TNS
and TNS/E native processes cannot share shm*() segments with each other. On TNS/R systems,
native and TNS OSS processes can share shm*() segments, but native Guardian processes cannot
share them with OSS processes (native or TNS).
OSS functions allow processes to share flat data segments. Guardian procedures allow processes
to share both flat and selectable data segments.
For more information on managing memory in the OSS environment, see the Open System Services
Programmer’s Guide.
NOTE: Beginning with the H06.20 and J06.09 RVUs, OSS and native Guardian processes can
share 64-bit memory using the SEGMENT_ALLOCATE64_ Guardian procedure. For information
about sharing 64-bit memory, see the 64-Bit Support in OSS and Guardian chapter in the Open
System Services Programmer’s Guide.
Using Semaphores
The use of a semaphore synchronizes the access of multiple processes to a shared resource. A
semaphore is a counter used to provide access to a shared data object for multiple processors.
Semaphores are an optional feature of the XPG4 specifications. OSS supports semaphores for
single-processor operations, and programs can use either XPG4 counting or Guardian binary
semaphores.
Using Interprocess Communication (IPC) Mechanisms 93