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

OSS semaphores are created and controlled with the semctl(), semget(), or semop() function
calls. OSS semaphores can be listed and deleted using the ipcs and ipcrm utilities (refer to the
semctl(2), semget(2), and semop(2) reference pages either online or in the Open System
Services System Calls Reference Manual and to the ipcs(1) and ipcrm(1) reference pages
either online or in the Open System Services Shell and Utilities Reference Manual for more
information).
Binary semaphores are created and controlled with the BINSEM_* Guardian procedures. They
can be used in both OSS and Guardian processes, and can be used to synchronize shared memory
between such processes. For information about the BINSEM_* procedures, see the following in
the NTL:
• Guardian Procedure Calls Reference Manual
• Summary of Guardian Binary Semaphore Procedures section in the Guardian Programmer's
Guide
Using the $RECEIVE File
The Guardian $RECEIVE mechanism is an interprocess communication mechanism that can be
used by OSS processes but makes them nonportable. Refer to “Using PROCESS_SPAWN_”
(page 98), “Starting a Guardian Server Process” (page 106), “$RECEIVE” (page 149), and to the
Open System Services Sockets Programmer’s Guide for more information.
Memory Model Considerations
For the TNS/R and TNS/E native environments and the G-series TNS environment, the HP C
compiler supports the large-memory model and the 32-bit (or wide) data model for OSS programs.
These models support 32-bit pointers and 32-bit int and long data types, which can also be
described as the ILP32 data model. (The HP TNS C compiler does not support the small-memory
model or the 16-bit data model for OSS programs.)
The default data model for native processes is ILP32. Though not explicitly named in this guide for
previous RVUs, this model been supported since the inception of TNS/R and TNS/E native processes.
TNS Guardian processes using the wide-data model (which is ILP32) can share flat 32-bit Guardian
segments with 32-bit OSS processes. Utilizing shared memory is less convenient if the TNS process
is not using the wide-data model, because some data types have different sizes. Sharing selectable
segments in TNS is very difficult and HP does not recommend doing it. The distinction between
flat and selectable segments, and how to use these shared memory segments, is discussed in detail
in the Open System Services Programmer’s Guide.
Beginning with the H06.24 and J06.13 RVUs on TNS/E systems, the HP TNS/E C/C++ compilers
support the following data models:
• ILP32: 32-bit int, long, and pointer data types for 32-bit OSS and native Guardian
applications
• LP64: 32-bit int, 64-bit long and pointer data types for 64-bit OSS applications
For information about these data models, see the 64-Bit Support in OSS and Guardian chapter
in the Open System Services Programmer's Guide.
This section introduces the memory models and data models for OSS programs and discusses
allocating and deallocating memory when working with OSS programs or porting applications to
OSS environment. Refer to the C/C++ Programmer’s Guide for details on the memory model in
the Guardian environment for native and TNS environments.
Also, see Chapter 8 (page 136), for memory-model incompatibilities that require conversion when
porting Guardian applications that use a memory-model not supported by OSS programs.
The large-memory model stores the heap and the program's global and static aggregates in a
single memory segment. (Static aggregate refers to an aggregate that is declared with the static
94 OSS Porting Considerations