Memory Management Policies and Multithreading

Table of Contents

• Memory Management
  • Using Custom Memory Allocators
• Thread Safety

Note

SW Release Applicability: This tutorial is applicable to modules in both NVIDIA DriveWorks and NVIDIA DRIVE Software releases.

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 Dynamic Memory.
• 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>

// setup memory allocator
dwDynamicMemory_initialize(myMalloc, myFree, myContext);

// initialize SDK

dwInitialize(&sdkContext, DW_VERSION, &contextParams);

...
// do processing
...

// release SDK context
dwRelease(&sdkContext);

// release memory allocator
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.