The NVIDIA® DriveWorks memory management policy defines conventions intended to protect modules from memory corruption during runtime.
Memory Management
For modules that require memory, the preferred method is static allocation (on the stack). When that is not possible, memory allocation is controlled with these conventions:
- During initialization/creation, modules use a memory allocator to dynamically allocate memory (on the heap). DriveWorks provides a default memory allocator; however, you can also supply your own custom memory allocator. See Using Custom Memory Allocators (below) and core_memory_group.
- Memory allocator APIs allocate dynamic memory only during initialization time (before runtime mode begins). With this restriction, dynamic memory allocation provides similar protections to static memory allocation.
Using Custom Memory Allocators
Before initializing a context, you can pass an instance of a custom memory allocator to the SDK. The SDK then uses the memory allocator to perform dynamic memory allocations.
- Note
- SDK modules do perform dynamic allocations only during initialization/creation time and perform no allocations at runtime.
#include <dw/core/DynamicMemory.h>
dwDynamicMemory_initialize(myMalloc, myFree, myContext);
...
...
dwDynamicMemory_release();
- Note
- As of this release, the user allocator is global. As such, it is not bound to a specific SDK context.
Thread Safety
Currently, the methods that DriveWorks modules expose do not follow any thread- safety paradigm. To avoid the overhead of memory locks, DriveWorks methods are considered to be non-thread safe. The exceptions are methods with documentation that explicitly indicate a thread-safe implementation.
Applications are responsible for implementing thread-safety, if such is required.