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.

Table of Contents

Memory Management

Using Custom Memory Allocators

Thread Safety