📄 rt_malloc.txt
字号:
RTAI Dynamic Memory Management Module.======================================The dynamic memory module for RTAI gives real time application programsthe ability to be able to dynamically create and free memory using thestandard UNIX programming API calls. Before this module real timeapplications which needed dynamic memory management had to use thestandard Linux kernel calls: kmalloc and kfree. This is potentially verydangerous as these calls can block, and if this were to occur from a realtime task the result is usually a total system lock up. The situation ismade worse as this can lead to intermittent bugs as real time applicationscan appear to work using these calls, but fail under varying loadconditions and circumstances.The dynamic memory manager module pre-allocates blocks (chunks) of memoryfrom the Linux kernel which is available for use by real time tasks usinga "UNIX like" API: rt_malloc and rt_free. The manager allocates and freesmemory from these blocks of memory, and also monitors the amount of freememory that is available in these blocks. When the amount of availablememory falls below a low water mark a request for another block of memoryis made pending. Similarly when the amount of available memory is greaterthan a high water mark a request to free a block of memory is madepending. These pending requests are carried out using either vmalloc andvfree or kmalloc and kfree calls at a safe time, ie when the real time systembecomes idle, just before control is handed back to Linux. Using thismechanism the memory manager balances the memory requirements of the realtime application with the need to keep as much memory as possibleavailable to the Linux kernel.Some of the reasons for using vmalloc are: - Simpler to share allocated buffers with user space. - Doesn't have the size restriction of kmalloc. (128KB)and for using kmalloc: - Faster. - Contiguous buffer address, needed by DMA controllers which don't have scatter/gather capability.The dynamic memory manager can be configured for the number of memoryblocks that are kept available, and the size of the blocks. This meansthat the module can be configured to meet the specific requirements andoperating conditions of a real time application, allowing the applicationto be programmed using the flexibility of dynamic memory allocation,whilst minimizing the memory resource burden on the Linux kernel. Anotherkey feature provided by the module is the ability to create real timethreads from other real time threads which is an essential feature formany applications. For this purpose, RT_TASK *rt_alloc_dynamic_task(void)has been added to the schedulers.Dynamic memory allocation for real time tasks is supported by theimplementation of the following functions:1/ void *rt_malloc(unsigned int size);rt_malloc allocates size bytes and returns a pointer to the allocatedmemory. If the allocation request fails a NULL is returned.2/ void rt_free(void *ptr);rt_free frees the memory space pointed by ptr which must have beenreturned by a previous call to rt_malloc. rt_free returns no value.The default configuration of the dynamic memory manager is:Memory block size: 64 KBytesNumber of free blocks kept available: 2These parameters can be changed if required by using the following moduleparameters:Memory block size: granularityNumber of free blocks kept available: low_chk_refFor example to change the size of the memory blocks to 32 Kbytes and thenumber of free blocks kept available for allocation to 4:insmod rtai_sched_up.o granularity=32768 low_chk_ref=4RTAI C++ Support Built Into The Module======================================Real time C++ support is provided with the implementation of the operators: void* operator new(size_t); void* operator new [](size_t); void operator delete(void*); void operator delete [](void*);These operators use the rt_malloc() and rt_free() primitives and thusmake it possible to execute real time C++ written modules. The LXRT directoryprovides an example on how to do this. Notice that C++ support is limitedas programs must be compiled with the -fno-exception g++ option. Also, an abstract base class that defines pure virtual functions should implementan empty function otherwise the compiler will generate the infamous __pure_virtual() call which will result in an unresolved symbol at insmodtime: class Wathever {public: virtual void foo() = 0; // This generates a __pure_virtual() call. virtual void Better {} // The empty function will not.};Alternatively you could choose to implement your own __pure_virtual()function with something like this:extern "C" void __pure_virtual();void __pure_virtual(){ RT_TASK *t; rt_printk( "%X calling a pure virtual\n", t = rt_whoami()); rt_task_suspend(t);}Notice that if you attemp to compile with the -fPIC option you willsee another infamous unresolved symbol: _GLOBAL_OFFSET_TABLE_.Also, you cannot instantiate global objects because nothing actuallydoes the global initialisation. This is normally done before the programenters main and you need to link with the library files crtbegin.o andcrtend.o to do that. However, linking with those two files will introduceyou to two other infamous unresolved symbols: __register_frame_info and__deregister_frame_info.To resume, C++ support is limited in that exception handling and globalinstantiation services are not available in the kernel due to lack of library support. It is possible to trick the compiler in order to avoid the __pure_virtual unresolved symbol.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -