[omniORB] local invocations

[Duncan Grisby]

On Thursday 8 November, Stefan Seefeld wrote:

> I can't wait to try it out. Let me try to put the requirements into 
> context to make this work properly and safely:
> 
> * no POACurrent

Correct.

> * calls are never serialized (you say 'threading policy is
>    ignored' without stating what the fallback mechanism is :),
>    i.e. I have to care for locking etc. in user code.

Also correct. If multiple threads access an object concurrently, the
calls are made to the servant concurrently, even if the POA has the
single thread or main thread policy.

> * I have to make sure objects aren't being deactivated while they are
>    in the middle of a call.
>    What does this last point mean ? I guess the POA doesn't obtain a
>    reference for the time of the method call, right ? Since I use ref
>    counted servants, what can I do to assure method calls and
>    deactivation are properly serialized ?

Normally, the POA increments a reference count (on an
omniLocalIdentity object) on the way in to a call, and decrements it
on the way out. This prevents the servant being deleted during a call.
Of course, to protect the reference count, a mutex must be locked /
unlocked on the way in and on the way out. This accounts for a lot of
time. If I hack my shortcut stubs to just do two mutex lock/unlocks in
addition to the shotcut call, the time for a call goes from 70ns to
740ns. Remember that a normal colocated call takes 1400ns without
POACurrent.

To be safe with the shortcut mechanism, you need to make sure no other
threads are deactivating the servants involved. It really depends on
how your application is structured as to how to do this. One simple
thing is to use something like a multiple reader / single writer lock,
where threads doing shortcut calls are readers, and threads doing
deactivations are writers. In fact, it's safe to have a multiple
reader / multiple writer lock. The only time this would get tricky
would be if you need to deactivate a servant in response to an
operation invocation. To cope with that, you'd have to defer
deactivation to a separate thread.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --