DriveWorks SDK Reference
3.5.78 Release
For Test and Development only

Memory Management Policies and Multithreading
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.

SDK modules do perform dynamic allocations only during initialization/creation time and perform no allocations at runtime.
// setup memory allocator
dwDynamicMemory_initialize(myMalloc, myFree, myContext);
// initialize SDK
dwInitialize(&sdkContext, DW_VERSION, &contextParams);
// do processing
// release SDK context
// release memory allocator
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.