The Ice run time itself is fully thread safe, meaning multiple application threads can safely call methods on objects such as communicators, object adapters, and proxies without synchronization problems. As a developer, you must also be concerned with thread safety because the Ice run time can dispatch multiple invocations concurrently in a server. In fact, it is possible for multiple requests to proceed in parallel within the same servant and within the same operation on that servant. It follows that, if the operation implementation manipulates non-stack storage (such as member variables of the servant or global or static data), you must interlock access to this data to avoid data corruption.
The need for thread safety in an application depends on its configuration. Using the default thread pool configuration typically makes synchronization unnecessary because at most one operation can be dispatched at a time. Thread safety becomes an issue once you increase the maximum size of a thread pool.
Ice uses the native synchronization and threading primitives of each platform. For C++ users, Ice provides a collection of convenient and portable wrapper classes for use by Ice applications.
On this page:
Threading Issues with Marshaling
The marshaling semantics of the Ice run time present a subtle thread safety issue that arises when an operation returns data by reference:
- Ice is marshaling this data, outside any synchronization under the control of the application
- At the same time, another request updates the same very same data
Ice provides an elegant solution for this problem with the marshaled-result metadata, available for the following language mappings:
Thread Creation and Destruction Hooks
On occasion, it is necessary to intercept the creation and destruction of threads created by the Ice run time, for example, to interoperate with libraries that require applications to make thread-specific initialization and finalization calls (such as COM's
CoUninitialize). Ice provides callbacks to inform an application when each run-time thread is created and destroyed.
The callback or callbacks are registered through the
InitializationData parameter passed to
To receive notification of thread creation and destruction, you must implement and register these callbacks. They will be called by the Ice run time by each thread as soon as it is created, and just before it exits.
For example, you could define callbacks and register them with the Ice run time as follows:
Installing Thread Hooks with a Plug-in
The thread hook facility described above requires that you modify a program's source code in order to receive callbacks when threads in the Ice run time are created and destroyed. It is also possible to install thread hooks using the Ice plug-in facility, which is useful for adding thread hooks to an existing program that you cannot (or prefer not to) modify.
Ice provides a base class named
ThreadHookPlugin for C++, Java, and C# that supplies the necessary functionality:
ThreadHookPlugin constructor installs the given thread callbacks into the specified communicator. The
destroy methods are empty, but you can subclass
ThreadHookPlugin and override these methods if necessary.
In order to create a thread hook plug-in, you must do the following:
- Define and export a factory class (for Java and C#) or factory function (for C++) that returns an instance of
ThreadHookPlugin, as described in the plug-in API.
- Implement the callback(s) that you will pass to the
- Package your code into a format that is suitable for dynamic loading, such as a shared library or DLL for C++ or an assembly for C#.
See the Plug-in Facility for more details on how to package and register your plug-in.