Threading Issues

#### Search Results

Search

# Threading Issues

A Natural process on Windows or Linux always contains only one thread that executes Natural code. Thus in an interactively started Natural session, it can never occur that several threads try to execute Natural code in parallel. The situation is different when a client program that runs several threads in parallel uses the Natural Native Interface.

The Natural Native Interface can be used by multithreaded applications. The interface functions are thread safe. As long as a given thread T is executing one of the interface functions, other threads of the same process that call one of the interface functions are blocked until T has left the interface function. Effectively the parallel executing threads of the process are serialized as far as the usage of the interface functions is concerned. It is not necessary to serialize interface access among the threads of different processes, because each different process that uses the NNI runs its own Natural session.

The calling application can also control the multithreaded access to the NNI explicitly. This can make sense if a thread wants to execute a series of NNI calls without being interrupted by another thread. To achieve this, the thread calls `nni_enter`, which lets the thread wait until all other threads have left the NNI. Then the thread does its work and calls NNI functions at will. After having finished its work, the thread calls `nni_leave` to allow other threads to access the NNI.

A multithreaded application that uses the NNI must follow these rules:

- The functions `nni_initialize` and `nni_uninitialize` must be called at least once per process.

- The function `nni_uninitialize` must be called on the same thread as the corresponding call to `nni_initialize`.

- The function `nni_uninitialize` must not be called before the last thread that uses the NNI has terminated.