30.12.2013 Views

T-Kernel Specification (1.B0.02)

T-Kernel Specification (1.B0.02)

T-Kernel Specification (1.B0.02)

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.6. MEMORY POOL MANAGEMENT FUNCTIONS 157<br />

TA TFIFO<br />

TA TPRI<br />

TA RNGn<br />

TA NODISWAI<br />

Tasks waiting for memory allocation are queued in FIFO order<br />

Tasks waiting for memory allocation are queued in priority order<br />

Memory access privilege is set to protection level n<br />

Wait disabling by tk dis wai is prohibited<br />

#define TA_TFIFO 0x00000000 /* manage task queue by FIFO */<br />

#define TA_TPRI 0x00000001 /* manage task queue by priority */<br />

#define TA_NODISWAI 0x00000080 /* reject wait disabling */<br />

#define TA_RNG0 0x00000000 /* protection level 0 */<br />

#define TA_RNG1 0x00000100 /* protection level 1 */<br />

#define TA_RNG2 0x00000200 /* protection level 2 */<br />

#define TA_RNG3 0x00000300 /* protection level 3 */<br />

The queuing order of tasks waiting to acquire memory from a memory pool can be designated in TA TFIFO<br />

or TA TPRI. If the attribute is TA TFIFO, tasks are ordered by FIFO, whereas TA TPRI designates queuing<br />

of tasks in order of their priority setting.<br />

When tasks are queued waiting for memory allocation, memory is allocated in the order of queuing.<br />

Even if other tasks in the queue are requesting smaller amounts of memory than the task at the head of<br />

the queue, they do not acquire memory blocks before the first task. If, for example, Task A requesting<br />

a 400-byte memory block from a variable-size memory pool is queued along with Task B requesting a<br />

100-byte block, in A-B order, then even if 200 bytes of space are free, Task B is made to wait until Task<br />

A has acquired the requested memory block.<br />

TA RNGn is designated to limit the protection levels at which memory can be accessed. Only tasks<br />

running at the same or higher protection level than the one designated can access the allocated memory.<br />

If a task running at a lower protection level attempts access, a CPU protection fault exception is raised.<br />

For example, memory allocated from a memory pool designated as TA RNG1 can be accessed by tasks<br />

running at levels TA RNG0 or TA RNG1, but not by tasks running at levels TA RNG2 or TA RNG3.<br />

The created memory pool is in resident memory in system space. There is no T-<strong>Kernel</strong> function for<br />

creating a memory pool in task space.<br />

[Additional Notes]<br />

If the task at the head of the queue waiting for memory allocation has its WAIT state forcibly released,<br />

or if a different task becomes the first in the queue as a result of a change in task priority, memory<br />

allocation is attempted to that task. If memory can be allocated, the WAIT state of that task is released.<br />

In this way it is possible under some circumstances for memory allocation to take place and task WAIT<br />

state to be released even when memory is not released by tk rel mpl.<br />

For the sake of portability, the TA RNGn attribute must be accepted even by a system without an MMU.<br />

It is possible, for example, to treat all TA RNGn designations as equivalent to TA RNG0; but error must<br />

not be returned.<br />

[Rationale for the <strong>Specification</strong>]<br />

The capability of creating multiple memory pools can be used for memory allocation as needed for error<br />

handling or in emergencies, etc.<br />

Copyright c○ 2002, 2003 by T-Engine Forum<br />

T-<strong>Kernel</strong> <strong>1.B0.02</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!