Hi! Wanted to know what else can cause semval value to increase, other than through semctl() SETVAL cmd, semop() with sembuf.sem_op of greater than 0, and kernel doing undo if semop() calls has SEM_UNDO flag set.

The problem I am experiencing is that N processes that use a shared library runs fine, then after some period of time (say after 5 hrs, or 9 hrs, or sometimes 15 hrs), it fails. During my debugging process, I found out that at some point, semval becomes 2, and one time, it became 3. I printed the semval through semctl() GETVAL cmd, after doing a lock of the semaphore.

The shared library is the one that creates or uses existing named semaphore, locks and unlocks the semaphore, and removes the semaphore if it identifies that no other process is using the semaphore. I am certain that I have all the lock/unlock pair in the code, and does not have an unlock semaphore call without a lock first. Also, semctl() SETVAL is done after the semaphore is created. If semaphore exists, I did not do semctl() SETVAL. Could it be that somehow, the kernel thought it needs to adjust the semval inappropriately? Or there is a problem because one of my processes has system() calls to a process that also uses the shared library? Or maybe because one of my processes has threads that uses the shared library might have confused the kernel?

I know it is not the best way to handle semaphores through a shared library, but I am stuck with this due to reasons beyond my control.

Thanks!