[omniORB] Efficiency of omniORB 3.

[David Riddoch]

On Thu, 18 Nov 1999, Duncan Grisby wrote:

> On Wednesday 17 November, b.keeping@ic.ac.uk wrote:
> 
> > We haven't yet started trying to use omniORB 3, but could you give a
> > little more detail about the additional work per local method
> > invocation?
> 
> The POA ensures that the semantics of local objects are identical to
> those of remote objects. This means that clients can be forwarded to
> other objects, objects can be activated on demand and exciting things
> like that. Unfortunately, this means that calls to local objects have
> to do a bit of mutex locking, etc., to protect against concurrency
> problems.
> 
> David Riddoch wrote it, so he'll be able to give you more details if
> you want them. Are you out there David?...

Okay, the interesting parts of the call chain looks something like this:

  stub -> omniObjRef::_invoke()       - method
  lock mutex
  omniObjRef -> omniLocalIdentity     - virtual
  omniLocalIdentity -> omniOrbPOA     - virtual
  unlock mutex
  omniOrbPOA -> local call fn         - fn call through ptr
  local call fn -> implementation     - virtual

The return path involves locking and unlocking a mutex, and passing
through a few catch() statements.

There are a lot of reasons why it genuinely does have to be this complex.
In fact I have gone to a lot of trouble to ensure that it is efficient as
it can be in both the local and remote cases, yet still adheering rigidly
to the spec.  The problem is that in a multi-threaded environment we have
to deal with the possibility of location forwarding into/out of our
address space, and the object being activated/destroyed under our feet.

Cheers,
David