Memory pool Management Functions

These functions are fully supported in this release:

ER get_blf(VP *p_blf, ID mpfid);

ER pget_blf(VP *p_blf, ID mpfid);

ER tget_blf(VP *p_blf, ID mpfid, TMO tmout);

ER rel_blf(ID mpfid, VP blf);

ER ref_mpf(T_RMPF *pk_rmpf, ID mpfid);

ER get_blk(VP *p_blk, ID mplid, INT blksz);

ER pget_blk(VP *p_blk, ID mplid, INT blksz);

ER tget_blk(VP *p_blk, ID mplid, INT blksz, TMO tmout);

ER rel_blk(ID mplid, VP blk);

ER ref_mpl(T_RMPL *pk_rmpl, ID mplid);

Note that of the memory provided for a particular pool to manage in the static initialization of the memory pool objects, some memory will be used to manage the pool itself. Therefore the number of blocks * the blocksize will be less than the total memory size.

The following functions are supported in this release, if enabled with CYGPKG_UITRON_MEMPOOLVAR_CREATE_DELETE or CYGPKG_UITRON_MEMPOOLFIXED_CREATE_DELETE as appropriate, with some restrictions:

ER cre_mpl(ID mplid, T_CMPL *pk_cmpl);

ER del_mpl(ID mplid);

ER cre_mpf(ID mpfid, T_CMPF *pk_cmpf);

ER del_mpf(ID mpfid);

Because of the static initialization facilities provided for system objects, a memory pool is allocated a region of memory to manage statically in the configuration (see the section called Component: Fixed-Size Memorypools in Chapter 15 and the section called Component: Variable-Size Memorypools in Chapter 15). So while memory pools can be created and deleted, the same area of memory is used for that memory pool (memory pool ID number) each time. The requested variable pool size (pk_cmpl->mplsz) or the number of fixed-size blocks (pk_cmpf->mpfcnt) times the block size (pk_cmpf->blfsz) are checked for fitting within the statically allocated memory area, so if a create call succeeds, the resulting pool will be at least as large as that requested. For this reason del_mpl() and del_mpf() do not in any sense free the memory that was managed by the deleted pool for use by other pools; it may only be managed by a pool of the same object id.

For both fixed and variable memory pools, the queueing order when waiting on a synchronization object depends on the underlying kernel configuration. The multi-level queue scheduler is required for strict µITRON conformance and it queues tasks in FIFO order, so requests to create an object with priority queueing of tasks (pk_cxxx->xxxatr = TA_TPRI) are rejected with E_RSATR. Additional undefined bits in the attributes fields must be zero.

In general, extended information (pk_cxxx->exinf) is ignored.

Error checking

The following conditions are only checked for, and only return errors if CYGSEM_UITRON_BAD_PARAMS_RETURN_ERRORS is enabled: