Re: [perfmon2] Self monitoring threads

[stephane e. <er...@go...>]

Hello John,


On Fri, May 1, 2009 at 12:51 AM, john <sy...@vi...> 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.