Hello John,
On Fri, May 1, 2009 at 12:51 AM, john <sy...@viscous.org> wrote: > Hello Stephane et al., > > My goal is to have an arbitrary number of threads monitor themselves, > each being interrupted after approximately 1ms worth of clock cycles > have gone by. Libpfm's example program self_smpl_multi seemed to do > something similar, so I rewrote it to take an arbitrary number of > threads and an arbitrary number of desired interrupts per second. > > I followed self_smpl_multi's technique of arranging to receive a SIGIO > in the thread associated with the Perfmon context, landing in the > registered signal handler. The threads continue running until they've > reached the targeted number of interrupts. For example, 10 > interrupts/second times five seconds of runtime would be 50 total > interrupts. > > This approach works fine up to about 25 interrupts/thread/second on my > Intel Core2 Quad (4 core) system. After that, some of the threads never > stop. Peering at the program in GDB leads me to believe that one or more > threads doesn't get SIGIO anymore. My current guess is that if any one > thread is handling SIGIO, any new notifications on other threads just > get dropped on the floor; the descriptor doesn't get read, so the signal > handler doesn't get invoked anymore. > Yes, you are running into the issue with the pthread signal model. There is no guarantee asynchronous signals such as SIGIO get delivered to the right thread. Last time I looked a the kernel code, it works as a job queue for the process, which ever thread is exiting the kernel may pickup the next signal job on the queue. Therefore it is not possible to guarantee which thread is going to get called. But this is also why, the handler you be prepared to handle notifications from another thread. The file descriptor should be sufficient to identify which thread the overflow originated with. > Would real time signals help me here (to queue up the signals), or is > there some other approach to thread interruption I should explore? > It seems that using realtime signals does help, use a signal >33 and you should get a better behavior. ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
