From: Colin Nevin (colin_nevin at domain yahoo.com)
Date: Fri 06 Sep 2002 - 11:24:26 IST
I have a question which is a bit tricky and was
wondering of anyone has come across this problem
before or could point me in the right direction.
I am involved in porting a SCO unix application to
Linux, and we have encountered a problem with the way
semaphores are being handled. The application uses
mulitple processes to run application code with the
main process known as the bsh which controls all i/o
be it screen, or file i/o, syncronisation is handled
In certain circumstances the main process and the
application child process seem to lock up both waiting
for the syncronisation semaphores to change state, I
have attached ddd to the processes and it seems that
the semaphore code is doing the correct things for
syncronisation but the processes stay stuck in the
semop() system call.
I have also noticed that if I introduce a slight delay
between changing semaphore states the problem goes
away, but this causes our entire application to run
really sloooww !! lol
Is there anything weird or different with the standard
implemenation of semaphores on modern linux that could
cause a semop() to fail to pick up the change in state
in a semaphore immediately?
Setting sem_flg = IPC_NOWAIT and checking for errno ==
EAGAIN and recalling semop() if the semop() call fails
(-1) also fixes the problem but again system
performance goes down the toilet.
both the parent controlling process run as the same
uid, and the parent creates the semaphores with
Any pointers would be appreciated!
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:42 GMT