DosSubSetMem initializes a memory pool for suballocation, or increases the size of a previously initialized memory pool.

The requester must first allocate or gain access to the memory object in which the memory pool resides using one of the memory-management function calls.

All calls to DosSubSetMem must eventually be followed by a call to DosSubUnsetMem. This is necessary to allow the suballocation function to reset resources used to manage the memory pool.

The size of suballocation control information in the memory pool is 64 bytes. Therefore, the minimum size for DosSubSetMem is 72 bytes.

The requester should not issue DosSetMem or change the attributes of any pages spanned by a memory object that the suballocation function is managing. Otherwise, unpredictable results may occur.

All the pages spanned by the memory pool must have the same attributes. At least Read/Write access must have been requested for the pages spanned by the memory pool when the memory is allocated.

The DosSubSetMem(Grow) function is closely related to the memory and performance requirements of the requester as follows:

• If the requester requires the best performance possible on DosSubAllocMem and DosSubFreeMem functions, and a guarantee that those requests will not fail due to a lack of space on the swap device, the requester should not use the Sparse feature, because the suballocation function will dynamically commit pages and request swap file storage.

  This type of requester may wish to notify the suballocation function later that more committed memory is now available for the memory pool by using the DosSubSetMem(Grow) function.

• Most requesters do not have this kind of requirement. They should allow the suballocation function to manage the pages occupied by the memory pool, and they should initialize it with the Sparse attribute. This type of requester should not have to issue a DosSubSetMem(Grow) function later.

Note: DosAllocMem and DosAllocSharedMem both allocate a block of memory of the size requested rounded to the nearest page. On OS/2 Warp, the system allocates a 64K object without attributes on every allocation.

For example, for a DosAllocMem call with a size of 1, the following occurs:

• On OS/2 Warp Connect, the system allocates a 4096-byte block of committed memory. 
  On OS/2 Warp, the system allocates a 4096-byte block of committed memory plus 61440 bytes without attributes.

  Note:

  When you allocate a memory object with the PAG_EXECUTE attribute, it is implied that this memory object also has the PAG_READ attribute. However, when querying the attributes of a memory object, you will get the following results:

  • On OS/2 Warp Connect, both PAG_EXECUTE and PAG_READ attributes are returned.

  • On OS/2 Warp, only the PAG_EXECUTE attribute is returned. However, PAG_READ is still implied.

  ---

  [Back] [Next]