[omniORB] single-threaded policy

[Duncan Grisby]

On Thursday 18 October, Bruce Fountain wrote:

> If I want to ensure that all incoming requests are handled
> in a single thread then I can create a custom POA using the
> SINGLE_THREAD_MODEL policy and activate my servant using it.
> 
> If I want to fix my objectid (so that I can use the abbreviated
> INS-style IOR "corbaloc::host:port/id") then I can use the
> special POA "omniINSPOA" to activate my servant.
> 
> What if I want to do both? Is there a way of creating a POA
> which supports both features?

No, there isn't. All the single thread model does is wrap all calls in
a mutex lock/unlock, so it's trivial to do it yourself. Just declare
an omni_mutex in your servant class (or somewhere global if you need
synchronisation between different servants), and put an
omni_mutex_lock object on the stack as the first thing you do in each
operation implementation.

> On the subject of single-threadedness: the only ORBacus feature
> that I really miss is the reactive single-threaded model. This
> lets you handle all incoming requests in a single thread yet
> prevents deadlock by allowing new requests to be received while
> another incoming request is making an outgoing call. I don't
> think that omniORB3 supports anything like this, but is there
> any chance that omniORB4 will support such an option?

No, omniORB 4 will not have a reactive threading model. I don't think
that model of working fits particularly well with omniORB's
multi-threaded design, but it might be possible to do in some future
version.

Personally, I feel that a reactive model lulls you into a false sense
of security about concurrency issues. It gives the impression of being
safe, since it's single-threaded, but it still has a lot of the
potential for re-entrancy that causes headaches in fully
multi-threaded code. Basically, you have to be prepared for a
re-entrant call whenever you do something that might involve a remote
call. That is often a harder condition to meet than if you were fully
multi-threaded, where you could occasionally hold locks across remote
calls.

Cheers,

Duncan.

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