[omniORB] Severe omniORB4 performance problems with local calls and "foreign" threads

[Duncan Grisby]

On Friday 16 August, Chris Newbold wrote:

> We've run into a rather severe performance problem with omniORB4's
> handling of local calls on "foreign" threads: threads created through
> some API other than omnithreads.
> 
> The culprit is poaCurrentStackInsert: when it discovers that the current
> thread is not an omnithread, it allocates a "temporary" omniCurrent and
> a "temporary" omni_thread (omni_thread_dummy). It allocates, initializes
> and destroys these objects for each local invocation. Needless to say,
> this savages the performance of local calls.

Indeed.

> We have our own C++ threading library which handles the same situation
> in a more efficient manner. Our thread abstraction, util::Thread, has a
> static member function to access the "current" thread:
> 
> 	static util::Thread* Self();
> 
> The constructor of util::Thread stuffs a pointer to itself into
> thread-specific storage and this is what util::Thread::Self() returns.
> If we find ourself in Self() and our pointer is zero, we're dealing with
> a "foreign" thread. We proceed to allocate a new instance of
> util::Thread and attach it to the existing thread and go on our way. We
> never explicitly remove our util::Thread object, so future calls to
> util::Thread::Self() on that thread are fast: it is no longer "foreign".
> 
> We install a destructor function for our thread-specific data to take
> care of deleting the util::Thread instance when the thread exits.

That's the problem. Not all platforms have a way to register a
destructor for thread specific storage (Windows, for example). On
those platforms, the storage would be leaked.

Look in omnithread.h at the create_dummy() and release_dummy()
functions, and the ensure_self class. If possible, you can use those
in your code to create and destroy the omnithread data yourself, thus
preventing the repeated creation and destruction of it by omniORB.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --