gcov in multithreaded applications

gcov in multithreaded applications

[daelen]

I am working with Gnat 3.13a on Windows NT 4.0.

I would like to use gcov to profile our application containing several
tasks.
The problem is that the da-files are written when the application exits,
but because most tasks contain infinit loops, the main program will not
exit.
I tried Win32.Winbase.ExitProcess but no da-files are written then.

- so how to write intermediate profiling info to the da-files without
having to exit the application.
- or how to exit or terminate the application in such a way that the da-
files are written.
Note that aborting the tasks is not an option because not all tasks-
names are known or in scope.

Regards,
Jorg van Daelen


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: gcov in multithreaded applications

[Robert A Duff]

daelen@my-deja.com writes:

> Note that aborting the tasks is not an option because not all tasks-
> names are known or in scope.

Task names don't need to be visible in order to abort them.  You can use
package Ada.Task_Identification.  You could have each infinitely-looping
task register itself (ie put its ID in some data structure).  Then you
could abort all those tasks at the appropriate time, from some central
place.

Alternatively, you could make each task do an ATC:

    task body T is
    begin
        select
            delay 10.0;
        then abort
            loop -- infinite loop here
                ...
            end loop;
        end select;
    end T;

Then all the tasks will go away after approx 10 seconds.

A better solution would be to simply write out the profiling data -- it
seems ugly to add complexity to your application just for the sake of
profiling.  I imagine there's a way to do that, but I don't know what it
is.

- Bob

Re: gcov in multithreaded applications

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]


<daelen@my-deja.com> a �crit dans le message news: 8oip2j$ut0$1@nnrp1.deja.com...
> I am working with Gnat 3.13a on Windows NT 4.0.
>
> I would like to use gcov to profile our application containing several
> tasks.
> The problem is that the da-files are written when the application exits,
> but because most tasks contain infinit loops, the main program will not
> exit.
> I tried Win32.Winbase.ExitProcess but no da-files are written then.
>
> - so how to write intermediate profiling info to the da-files without
> having to exit the application.
> - or how to exit or terminate the application in such a way that the da-
> files are written.
> Note that aborting the tasks is not an option because not all tasks-
> names are known or in scope.
>
Yes it is. There is a very simple way to abort all tasks in a system.
In the main procedure (or some library package) have:
   Anonymous_Task : constant Task_ID := Current_Task;

and then:
   Abort_Task (Anonymous_Task);

(of course, you need to with Ada.Task_Identification). Since the main program is executed by the anonymous task, and since all tasks
have (directly or indirectly) the anonymous task as one of their masters, this is guaranteed to kill everything. Have a look at
package Debug from Adalog's component page (http://pro.wanadoo.fr/adalog/compo2.htm) for more details on that kind of techniques.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: gcov in multithreaded applications

[Dr Adrian Wrigley]

daelen@my-deja.com wrote:
> 
> I am working with Gnat 3.13a on Windows NT 4.0.
> 
> I would like to use gcov to profile our application containing several tasks.

If I my experience profiling code with multiple tasks is virtually futile.

At least on the Gnat 3.11/Linux on Intel architecture, the basic block
counting code is not thread-safe :(  This stops reliable block profiling
with gcov under gcc.  I was using native (Linux) threads.

Further, the function/procedure counting was not thread safe either
(the mcount does not protect the count).  This leads to spurious
values in a "gprof" profile of function counts/timing.

I was unable to resolve the problem under support from ACT, as it
seems to be a problem with the "mcount" in the profiling library,
and gcov style block profiling doesn't seem to be supported.

I had some success with my own thread-safe alternative to "mcount",
but the performance drag was very significant (worse than 3x for
heavily nested calling).  Also, some success enabling profiling
dynamically on a per function basis, by one thread at a time.

All this is from memory of over a year ago.  Things may have changed.
I may have misremembered. Profiling on NT may have fixed the gcov bug.

Did you get the results you wanted, Jorg?  Were they reliable?
--
Adrian Wrigley.