UNIX for Dummies Questions & Answers

I have a situation where I have created a semaphore and set it's value to 10. I am using this semaphore to control access to a shared memory location. I can have 10 processes simultaneously read from the shared memory location, process 11 would get locked out. My question is, is there a way I can find out which processes have currently called semop and have obtained the semaphore, and if so what was the value the decremented the semvalue by? I would like to know this so if a process already has obtained the semaphore I can block them from calling semop again and using a 2nd.

Shouldn't the processes post on the semaphore when they're done? And what's so magical about ten, why can ten processes safely share it but not eleven?

semctl can tell you the last time a semop happened to something, but not who did it, or what. I don't think it 'remembers' who has 'access' beyond the normal scope of a sem either; it either suspends processes or not depending on its current value, and keeps a list or waiters to wake when posted on. Perhaps the sem's other access control features can be used to control what processes can wait on it, changing the process' group ID's and such.

From what I can determine the last process to interact with a semaphore stores it's pid in the semaphore buffer area.

Don't get hung up on 10. 10 was just a number I pulled out of my ---- When a process goes to read from the shared memory it will decrement the semvalue by 1. When it is done reading it increments it by 1. This allows for shared read access to the memory. When a process wishes to write to the shared memory it will decrement (in this example) the semvalue by 10, thus locking out all processes to ensure that while it is updating the memory another process is not trying to read from it and get bogus data.

So what I want to prevent is a deadlock where a process reads memory decrementing semvalue by 1 then tries to request exclusive access. I would like to be able to determine that this process has already decremented the semvalue by 1 and therefore only needs to decrement by 9 to get exclusive access instead of 10.

Can't the process itself remember when its used a semaphore before? Sems don't have that kind of memory, they're just counters and a queue. I've written and deleted many solutions here, realizing partway through that they all fail when a process can't remember how many times its locked it already.

Yeah, the process itself could keep track, I was trying to come up with a more "elegant" way. To protect from lazy developers.

Giving them a library function might work for that.