Re: Is this stack trace normal?

In article <19961220074500.CAA02432@ladder01.news.aol.com>, SaTriGuy <satriguy@aol.com> writes >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. > > Could you please e-mail me the original stack trace? I would be interested in it and missed the original question. My internet provider "LOSS" between 20,000 and 30,000 articles a few days ago!! -- David Williams