[omniORB] A thread problem in OmniORB

[Sai-Lai Lo]

Jose,

Its hard to say if the problem you have is related to thread priority or just
race conditions.

Perhaps it is better to restructure you code to have a designated thread to
communicate with the serial port. Any other threads, for instance, the
upcall threads from the ORB to your CORBA server will communicate with this
designated thread via a producer-consumer queue. In this way, the
designated thread has complete control on whether to stuff more commands
down the serial port or to read stuff off it. At the moment, your listener
thread may be losing out to the upcall threads in the battle for grabbing
mutual exclusion on the serial port.

Sai-Lai


>>>>> Jose Luis Ajuria writes:

> Dear list members,
> I have a semi-starvation problem with OmniORB 2.7.1 for NT and a 
> communication library from us. Please, if you think that this problem is 
> solved in 2.8, please let me know.

> The CORBA-OmniORB server is conected to a machine using a serial port. 
> We have one thread for serial port listening, that is created in the constructor 
> of the server implementation object (derived form _sk_...).
> In this constructor I create a new thread that communicates with the 
> machine for monitoring, using this new thread for output and the previous 
> thread for input.
> This function works fine most of the times (sometimes it also fails like the 
> following one, but very rarely).

> The problem comes when I remotely invoke from a client a service of the 
> CORBA server that communicates with the machine. As the new CORBA-
> service is executed in a new thread, I write in the serial port in this new 
> thread and the problem comes in the reading thread, that was created at 
> starting the server application. I think that this thread looses priority and 
> input from machine becomes slow, and then timeouts occur in 
> communication.
> Of course I use a Mutex for access to the port and then to block the thread 
> that was created in the constructor for monitoring and then avoid output from 
> two different points (the service thread and the monitoring thread).

> Please, could you help me ?





-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND