[omniORB] optimizing a multi threaded CORBA application

[Stefan Seefeld]

hi,

while we are optimizing the berlin display server we realize that one 
of the performance bottlenecks is mutex locking/unlocking. We therefor 
try to figure out whether we could avoid some of the mutexes, which would 
require us to have more control over threading/concurrency issues than we 
currently have with CORBA 2.3.

The situation is this:

we have a scene graph, consisting of 'Graphic' nodes, each holding
references to parents and children. Currently, each Graphic implementation
contains mutexes to protect access to these references.
It now appears, that in a traversal operation the locks of these mutexes
are the most offending performance-wise. The question is whether we could
drop the mutexes and replace them with a singleton mutex, protecting not
individual graphics but the whole traversal operation at once.

This, however, would require that we control the data flow much more than
we currently can. Note, for example, that we use multiple POAs, so using
SINGLE_THREAD as a POA policy wouldn't help. Note as well that we don't want
to drop multi threading as a whole, just serialize scene graph access while
a traversal is taking place.

Further, I believe that the kind of restriction we would need isn't strictly
related to threading. Consider the following example of two nested 'callbacks'

client                  server
             foo()
      <----------------  thread X waits for foo() to finish
             bar()
      ---------------->  thread Y processes bar() request
      return from bar()
      <----------------
      return from foo()
      ---------------->

Here, the server thread calling foo() may still wait for the call to finish,
while another thread takes up the bar() call. While it is a different thread,
it's the same context, i.e. part of the same line of data flow (what's the 
correct term for this ?) and should therefor be allowed. Any other, unrelated 
request from the client, however, should be blocked.

Is there any way to control this kind of access ? The GIOP has a 'request_context'
field. Can it be used for that kind of control ? Does the RT CORBA spec add any
policies concerning that kind of situation ? What about Portable Interceptors ?

The aim here is really to make the server more efficient, i.e. to reduce the number
of mutex locks/unlocks without compromizing complete access serialization. Note that
'normally' the scene graph is fully contained in the server, i.e. remote requests as
part of a traversal are (or should be) extremely rare.

I'm afraid I'm not very clear with my explanation, sorry...

Any hints or suggestions are highly welcome !

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...