I have a radical proposal to remove the need for locking: make the CmdStatusSlot struct consist of a mere dsm_handle and move all the required metadata like sender_pid, request_type, etc. into the shared memory segment itself.
If we allow the only the requesting process to update the slot (that is the handle value itself) this removes the need for locking between sender and receiver.
The sender will walk through the slots looking for a non-zero dsm handle (according to dsm_create() implementation 0 is considered an invalid handle), and if it finds a valid one, it will attach and look inside, to check if it's destined for this process ID. At first that might sound strange, but I would expect 99% of the time that the only valid slot would be for the process that has been just signaled.
The sender process will then calculate the response message, update the result_code in the shared memory segment and finally send the message through the queue. If the receiver has since detached we get a detached result code and bail out.
Clearing the slot after receiving the message should be the requesting process' responsibility. This way the receiver only writes to the slot and the sender only reads from it.
By the way, is it safe to assume atomic read/writes of dsm_handle (uint32)? I would be surprised if not.
I don't see any reason why it should not to work - only few processes will wait for data - so lost attach/detach shm operations will not be too much.
Please see attached for implementation of this approach. The most surprising thing is that it actually works :)
One problem still remains with the process requesting information when the target process exits before it can have a chance to handle the signal. The requesting process then waits forever, because nobody attaches/detaches the queue. We've discussed this before and looks like we need to introduce a timeout parameter to pg_cmdstatus()...
