Mail Archives: cygwin/2003/10/15/13:21:19
On Wed, 15 Oct 2003, peter garrone wrote:
> Brian Ford wrote:
> >On Tue, 14 Oct 2003, peter garrone wrote:
> >> A list of active threads is maintained. A thread calling moncontrol(1) gets
> >> put in the list. When a call to SuspendThread fails, the thread is assumed
> >> to be defunct and taken off the list.
> >>
> >Seems reasonable.
> >
> >I guess I was originally thinking "just profile all threads all the
> >time", but I guess your method is more flexable. That could
> >probably be an option somehow after you polish this up.
>
> There is no other way to detect a dead thread. Nothing like "atexit" or
> anything I could find anyway in the win32 api, of which my experience
> is limited, and ordinary.
>
Sorry, I wasn't disputing that, but it sounded like Corinna had a good
suggestion here.
I just thought it would be nice if compiling with -pg automatically
profiled all threads. It is really just a policy decision on other OSs.
Maybe it could be configurable based upon an environment variable or
something. In that case, you would need to look inside Cygwin for a list
of threads and a notification method for new ones. Or maybe just
arrange for all Cygwin created threads to call moncontrol(1) in that
case. Maybe Corinna has a good suggestion here as well.
I'm starting to get out of my leage/time commitment here. I'm good at
making architecture suggestions, but I'm short on implimentation details.
:)
> >What is your tick definition? A sampling interval?
>
> Yes.
> The amount of CPU usage corresponging to a loop of the profiling sampler.
> The amount represented by incrementing the sample data by one.
>
These two are the same.
> The amount of time represented by (1.0/PROF_HZ)
>
This is absolute, and I see below how this is different.
> >How can a thread ever consume more that 100%? I can see how two or more
> >threads might on a multi CPU system.
>
> The profiling thread calls Sleep. That function is guaranteed to sleep for
> at least its argument. It can always sleep longer. So the actual
> profiling interval could be longer than the nominal profiling interval.
> In the meantime, a thread could have consumed more than one interval
> worth of cpu.
>
Ok, I see. I think most implimentations would just throw the partial tick
away. It seems like trying to account for it gets way too messy,
especially since you only have one PC sample value.
> >I'm lost in the random number generator application too.
> >
> 1) The rng algorithm itself
>
Sorry, I wasn't clear enough here too. Thanks for the description, but I
really just wanted to know how you were applying it to partial ticks.
> 2) Why use one?
>
> What else do you do if only a fraction of a tick
> is used. If a thread has consumed say 70% of a complete ticks worth of cpu,
> then roll the dice and 70% of the time assign a tick. I dont think I can
> explain it better. It all averages out in the end, and its basically an
> estimate anyway.
>
The sample is usually considered the smallest granularity possible since
it is the only thing you have a PC for. You are getting sub atomic timing
data, but only have atomic units of assignment.
If you're sure it helps, great! To me, it seems like you're trying to use
more digits than are significant. I'd just take the thread that consumed
the most CPU's PC and give it the tick, but I'm lazy.
> Concerning the DLL import function profile assignment solution,
[snip]
> However when I try things like the cygwin dll
You can't replace the cygwin1.dll's import library. It has magic
redirections and such in it. You could modify it, though.
Sorry, the rest is beyond what I have time to think about.
> Setup hangs at the last.
>
Obviously, this is a normal state for some. Don't run it from explorer
and you should be ok.
> Any suggestions on this, by anyone at all, would be greatly appreciated.
>
This might be more suited for cygwin-developers. Have you tried to jump
through those hoops yet (if you're interested, that is)?
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -