[omniORB] thread policy per interface function
Duncan Grisby
duncan at grisby.org
Fri Aug 17 20:05:41 BST 2007
On Friday 17 August, Thomas Lockhart wrote:
> >> The downside is that you will be tying up ORB threads while they wait
> >> for the mutex to become free.
> > That doesn't make any difference. omniORB implements the single thread
> > model with a recursive mutex, so using a mutex in application code is no
> > different.
>
> I was assuming a multi-threaded model with individual methods forcing
> single-thread behavior by holding application-level mutexes. Is there
> a fatal flaw in that configuration?
Not at all. I think that's the right thing to do. My point was that
omniORB's single thread model does exactly the same thing, so ORB
threads are tied up waiting for the lock regardless of whether it's the
mutex in the ORB or a mutex in the application.
There's nothing particularly special about a single thread policy POA --
it just has a lock around method calls.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list