[omniORB] Deadlock in omniCallHandle ?

[Regis DETRE]

Hello,

I am using omniORB 4.0.6 in a very large software under SUN Fire / SOLARIS 
10 SPARC (a lot of servers) and I've experience what seems to be a kind of 
deadlock.

Our servers rely now on a main thread model because we need to serialize 
requests.
But sometimes, in some servers for apparantly no specific reason, the main 
thread is waiting for an event whereas the are pending requests in 
"listener threads".
I have checked my code under Purify, debugger and I've instrumented many 
files, I have not been able to find an obvious bug.

What I have identified form now is that the last processed request, when 
completed, should notify main thread to handle pending requests (end of 
omniCallHandle::execute). But apparently, under SOLARIS (though using 
POSIX pthread in lib omnithreads), the final call to pd_cond->signal() do 
not work as expected.

Reading man on pthread, we must take care on the fact that a call to 
signal will wake up "at least" one waiting thread, which I guess do not 
mean "all of them"
Then, I've replaced pd_cond->signal() by pd_cond->broadcast() and I do not 
get any dead lock at all.

This problem is very difficult to reproduce on a simple example because it 
seems it depends on a very specific processing duration (no dead lock with 
SOLARIS 10 SPARC on SUN U60, much slower).

This patch might not be correct for every omniORB target platform (maybe I 
should haved tuned omni_thread thread policies for semafore handling, but 
not enough time to implement a global portable solution) but must work on 
most UNIX.

I've been reading that a future 4.0.7 version should be released soon, I 
wondered if sutch a patch could be part of it so that we upgrade our 
software quickly, before preparing the arrival of 4.1 ?

Thanks a lot for your assistance.

Fabrice Ferrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20051215/f34f909e/attachment.htm