Re: Is this stack trace normal?

While semaphores are often used to lock memory, that is not their only use. They are also used as a binary lock. What your are seeing is normal for a shared memory connection when the query has been passed to the engine. Let me explain. Each shared memory client is assigned a semaphore when it connects to the engine. When the client has passed a request to the engine, what is the client supposed to be doing while the engine is working on that request? We could put the client in a spin loop and keep checking to see if the engine had anything, but that would be wasting machine cycles. Or we could do the same loop, but go to sleep for a bit in each loop, but that would force the client to be sleeping when there might already be a response for it. What actually happens is that after the client places the request into the shared memory message segment, it locks it's assigned semaphore and then queues itself on that same semaphore. Since this is a blocking call, this causes the process to go into a wait state. When the engine has placed data back in the message buffers for that same client, it wakes the client program by simply unlocking the semaphore for that client. This causes the kernel to more the process from a wait state to a ready state and the client program simply reads the data from the message buffers that was left by the engine.