Re: Is this stack trace normal?

David Anderson wrote: > > I'm using Informix online 7.1 on an alpha running unix. > I access the db using esql/C programs. > When I interrupt these programs in the debugger, > the stack trace ALWAYS starts as follows: > > #0 0x3ff828d90a8 in semop () > #1 0x12007e394 in buf_wait () at shm_fe.c:1874 > #2 0x12007d85c in recvshm () at shm_fe.c:1089 > #3 0x1200685d4 in ASF_Call () at asfapi.c:413 > #4 0x120093c8c in asf_recv () at ospipe.c:1047 > #5 0x120093d74 in _iread () at ospipe.c:1116 > #6 0x120092d00 in _igetint () at ospipe.c:315 > #7 0x12005d6dc in _sqr_messages () at iqreturn.c:925 > #8 0x1200488d0 in __slct () at iqsimple.c:425 > #9 0x12004871c in _iqslct () at iqsimple.c:303 > > Are my programs really spending 99% of their CPU time > spinning on a semaphore? > Is this a configuration problem? David any I/O bound process spends 99% of its time waiting for something. In this case, the I/O is probably the TCP service port. If you are connecting to the engine via shared memory, your app waits for some indication that the data from the query is ready in shared memory. In short: It is indeed normal to be waiting on a semaphore 99% of the time. HOWEVER this is *not* spinning. A semaphore wait puts the process into a sleep state so your app will not be scheduled until something - perhaps the release of the semaphore - knocks it out of the sleep state. (In your case, it is your interrupt key.) BTW, I wish Unix had a more efficient way of awakening procs that are all waiting for a semaphore. From the way books tell us to use them, ALL processes waiting for that semaphore will wake up, immediately try to grab for it again. Of course, only one normally gets it so the others go back to sleep. That's one expensive & useless wake-up call for the majority. (Some might even have gotten swapped back it for this!) Speaking with 20/20 hindsight over the implementers' shoulders: It would have been so much more logical for Unix to simply queue processes to the semaphore! Still, that's an ineficiency built into Unix. The Informix "latch" mechanism tries to get around this to avoid contention among threads and virtual processes. This helps not a whit for your concerns, though I hope I have calmed down the panic over spinning. -- -- Jake Salomon +-----------------------------------------------------------+ | Diplomacy: The art of getting something off your | | chest without losing your shirt | +------------------------Alfred E. Neuman-------------------+