임베디드/[ RTOS ]

[ RTOS ] 07. ThreadX의 Memory Block Pools

kim.svadoz 2021. 4. 5. 10:20
728x90
반응형

Memory Block Pools

Allocating memory in a fast and deterministic manner is always a challenge in real-time applications. With this in mind, ThreadX provides the ability to create and manage multiple pools of fixed-size memory blocks.

Since memory block pools consist of fixed-size blocks, there are never any fragmentation problems. Of course, fragmentation causes behavior that is inherently un-deterministic. In addition, the time required to allocate and free a fixed-size memory is comparable to that of simple linked-list manipulation. Furthermore, memory block allocation and deallocation is done at the head of the available list. This provides the fastest possible linked list processing and might help keep the actual memory block in cache.

Lack of flexibility is the main drawback of fixed-size memory pools. The block size of a pool must be large enough to handle the worst case memory requirements of its users. Of course, memory may be wasted if many different size memory requests are made to the same pool. A possible solution is to make several different memory block pools that contain different sized memory blocks.

Each memory block pool is a public resource. ThreadX places no constraints on how pools are used.

빠르고 결정적인 방식으로 메모리를 할당하는 것은 실시간 애플리케이션에서 항상 어려운 일입니다. 이를 염두에두고 ThreadX는 고정 크기 메모리 블록의 여러 풀을 만들고 관리하는 기능을 제공합니다.

메모리 블록 풀은 고정 크기 블록으로 구성되므로 조각화 문제가 전혀 없습니다. 물론 조각화는 본질적으로 결정적이지 않은 동작을 유발합니다. 또한 고정 크기 메모리를 할당하고 해제하는 데 필요한 시간은 단순한 연결 목록 조작의 시간과 비슷합니다. 또한 메모리 블록 할당 및 할당 해제는 사용 가능한 목록의 선두에서 수행됩니다. 이것은 가능한 가장 빠른 연결 목록 처리를 제공하고 실제 메모리 블록을 캐시에 유지하는 데 도움이 될 수 있습니다.

유연성 부족은 고정 크기 메모리 풀의 주요 단점입니다. 풀의 블록 크기는 사용자의 최악의 메모리 요구 사항을 처리 할 수있을만큼 충분히 커야합니다. 물론 동일한 풀에 대해 서로 다른 크기의 메모리 요청이 많이 발생하면 메모리가 낭비 될 수 있습니다. 가능한 해결책은 다른 크기의 메모리 블록을 포함하는 여러 다른 메모리 블록 풀을 만드는 것입니다.

각 메모리 블록 풀은 공용 리소스입니다. ThreadX는 풀이 사용되는 방식에 제한을 두지 않습니다.

  • Creating Memory Block Pools

Memory block pools are created either during initialization or during run-time by application threads. There are no limits on the number of memory block pools in an application.

메모리 블록 풀은 초기화 중에 또는 런타임 중에 애플리케이션 스레드에 의해 생성됩니다. 애플리케이션의 메모리 블록 풀 수에는 제한이 없습니다.

  • Memory Block Size

As mentioned earlier, memory block pools contain a number of fixed-size blocks. The block size, in bytes, is specified during creation of the pool.

ThreadX adds a small amount of overhead—the size of a C pointer—to each memory block in the pool. In addition, ThreadX might have to pad the block size in order to keep the beginning of each memory block on proper alignment.

앞서 언급했듯이 메모리 블록 풀에는 여러 고정 크기 블록이 포함됩니다. 블록 크기 (바이트)는 풀 생성 중에 지정됩니다.

ThreadX는 풀의 각 메모리 블록에 약간의 오버 헤드 (C 포인터 크기)를 추가합니다. 또한 ThreadX는 각 메모리 블록의 시작 부분을 적절하게 정렬하기 위해 블록 크기를 채워야 할 수 있습니다.

  • Pool Capacity

The number of memory blocks in a pool is a function of the block size and the total number of bytes in the memory area supplied during creation. The capacity of a pool is calculated by dividing the block size (including padding and the pointer overhead bytes) into the total number of bytes in the supplied memory area.

풀의 메모리 블록 수는 블록 크기와 생성 중에 제공된 메모리 영역의 총 바이트 수의 함수입니다. 풀의 용량은 블록 크기 (패딩 및 포인터 오버 헤드 바이트 포함)를 제공된 메모리 영역의 총 바이트 수로 나누어 계산합니다.

  • Pool's Memory Area

As mentioned before, the memory area for the block pool is specified during creation. Like other memory areas in ThreadX, it can be located anywhere in the target’s address space.

This is an important feature because of the considerable flexibility it gives the application. For example, suppose that a communication product has a high-speed memory area for I/O. This memory area is easily managed by making it into a ThreadX memory block pool.

앞에서 언급했듯이 블록 풀의 메모리 영역은 생성 중에 지정됩니다. ThreadX의 다른 메모리 영역과 마찬가지로 대상 주소 공간의 어느 곳에 나 위치 할 수 있습니다.

이것은 응용 프로그램에 상당한 유연성을 제공하기 때문에 중요한 기능입니다. 예를 들어, 통신 제품에 I / O를위한 고속 메모리 영역이 있다고 가정합니다. 이 메모리 영역은 ThreadX 메모리 블록 풀로 만들어 쉽게 관리 할 수 있습니다.

  • Thread Suspension

Application threads can suspend while waiting for a memory block from an empty pool. When a block is returned to the pool, the suspended thread is given this block and resumed.

If multiple threads are suspended on the same memory block pool, they are resumed in the order they were suspended (FIFO).

However, priority resumption is also possible if the application calls tx_block_pool_prioritize prior to the block release call that lifts thread suspension. The block pool prioritize service places the highest priority thread at the front of the suspension list, while leaving all other suspended threads in the same FIFO order.

빈 풀에서 메모리 블록을 기다리는 동안 응용 프로그램 스레드가 일시 중지 될 수 있습니다. 블록이 풀로 반환되면 일시 중단 된 스레드에이 블록이 주어지고 다시 시작됩니다.

여러 스레드가 동일한 메모리 블록 풀에서 일시 중단 된 경우 일시 중단 된 순서 (FIFO)에 따라 다시 시작됩니다.

그러나 스레드 중단을 해제하는 블록 해제 호출 이전에 응용 프로그램이 tx_block_pool_prioritize를 호출하는 경우에도 우선 순위 재개가 가능합니다. 블록 풀 우선 순위 지정 서비스는 가장 높은 우선 순위 스레드를 일시 중단 목록의 맨 앞에 배치하고 다른 모든 일시 중단 된 스레드는 동일한 FIFO 순서로 둡니다.

  • Memory Block Pool Control Block TX_BLOCK_POOL

The characteristics of each memory block pool are found in its control block. It contains information such as the number of memory blocks left and their size. This structure is defined in the tx_api.h file.

Pool control blocks can also be located anywhere in memory, but it is most common to make the control block a global structure by defining it outside the scope of any function.

각 메모리 블록 풀의 특성은 해당 제어 블록에서 찾을 수 있습니다. 여기에는 남은 메모리 블록 수 및 크기와 같은 정보가 포함됩니다. 이 구조는 tx_api.h 파일에 정의되어 있습니다.

풀 제어 블록은 메모리의 어느 곳에 나 위치 할 수도 있지만 제어 블록을 모든 기능의 범위 밖에서 정의하여 글로벌 구조로 만드는 것이 가장 일반적입니다.

  • Overwriting Memory Blocks

It is very important to ensure that the user of an allocated memory block does not write outside its boundaries. If this happens, corruption occurs in an adjacent (usually subsequent) memory area. The results are unpredictable and quite often fatal!

할당 된 메모리 블록의 사용자가 경계 외부에 쓰지 않도록하는 것이 매우 중요합니다. 이 경우 인접한 (일반적으로 후속) 메모리 영역에서 손상이 발생합니다. 결과는 예측할 수 없으며 매우 치명적입니다!

728x90
반응형