This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
realtime:documentation:howto:applications:memory [2017/07/15 00:16] jithu [Dynamic memory allocation for RT usage] - review comm - wip |
realtime:documentation:howto:applications:memory [2017/07/15 01:55] jithu [Memory Locking] |
||
---|---|---|---|
Line 14: | Line 14: | ||
[[http://www.gnu.org/software/libc/manual/html_node/Locking-Pages.html|The GNU C Library: Locking pages]]. Note that these calls requires the application to have sufficient privileges (i.e. [[http://man7.org/linux/man-pages/man7/capabilities.7.html|CAP_IPC_LOCK capability]]) to succeed. | [[http://www.gnu.org/software/libc/manual/html_node/Locking-Pages.html|The GNU C Library: Locking pages]]. Note that these calls requires the application to have sufficient privileges (i.e. [[http://man7.org/linux/man-pages/man7/capabilities.7.html|CAP_IPC_LOCK capability]]) to succeed. | ||
- | While ''mlock(<addr>, <length>)'' locks specific pages (described by //address// and //length//), ''mlockall(...)'' locks an application's entire virtual address space (i.e [[realtime:documentation:howto:applications:memory:mlockall_globals_sample|globals]], [[realtime:documentation:howto:applications:memory:mlockall_stack_sample|stack]], heap, code) in physical memory. The trade-off between convenience and locking-up excess RAM should drive the choice of one over the other. Locking only those areas which are accessed by RT-threads (using ''mlock(...)'') could be cheaper than blindly using ''mlockall(...)'' which will end-up locking all memory pages of the application (i.e. even those which are used only by non-RT threads). | + | While ''mlock(<addr>, <length>)'' locks specific pages (described by //address// and //length//), ''mlockall(...)'' locks an application's entire virtual address space (i.e [[realtime:documentation:howto:applications:memory:mlockall_globals_sample|globals]], stack, heap, code) in physical memory. The trade-off between convenience and locking-up excess RAM should drive the choice of one over the other. Locking only those areas which are accessed by RT-threads (using ''mlock(...)'') could be cheaper than blindly using ''mlockall(...)'' which will end-up locking all memory pages of the application (i.e. even those which are used only by non-RT threads). |
Line 56: | Line 56: | ||
- | ===== Dynamic memory allocation for RT usage ===== | + | ===== Dynamic memory allocation in RT threads===== |
- | The suggested recommendation is for the RT threads to do malloc() and free() outside of its real-time critical phase. | + | Real-time threads should avoid doing dynamic memory allocation / free while in RT critical path. The suggested recommendation for real-time threads is to do the allocations before entering RT critical path. It is okay for the RT thread in RT critical path to access a dynamically allocated memory, provided that it is locked as described [[memory#Memory Locking|here]] . |
+ | |||
+ | Non RT-threads within the applications have no restrictions on dynamic allocation / free . | ||