Elena Laskavaia
|
How to know that thread is preempted?
|
Elena Laskavaia
11/07/2008 10:54 AM
post16202
|
How to know that thread is preempted?
I want to measure how much time function execution would take within function itself,
for example
void x() {
start = ClockCycles();
...
end = ClockCycles();
time = end-start;
}
Now if Thread where x is running gets preempted time would be wrong.
How can I know that? Any handlers I can install inside my app? Any other "time" related calls I can make instead, that
returns thread running time (or process time) instead of absolute time?
|
|
|
Hans-Peter Reichert
|
AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:10 AM
post16208
|
AW: How to know that thread is preempted?
I guess your aksing 'cause of the Application Profiler thing?!
I see two different things:
*1st - for doing profiling from k-traces
you don't need to mesaure the time at all on the target site, this yould be done on IDE site - cause you have all the
informations on the TraceEvent() entries
*2nd - for doing this on target site
a) maybe you can do this using dynamic event filtering
installing a handler on event RUNNING or/and others could give you some informations
b) in addition to do ClockCycles(), you can check the resulting delta against a 2nd delta you do on the THREAD_CPU_CLOCK
time
if this is "nearly" the same it should be OK
or
c) why not using THREAD_CPU_CLOCK *instead* of ClockCycles() ???
shouldn't this solve the problem?
OK it is more costley, but anything other?
/hp
>-----Ursprüngliche Nachricht-----
>Von: Elena Laskavaia [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 16:54
>An: ostech-core_os
>Betreff: How to know that thread is preempted?
>
>I want to measure how much time function execution would take
>within function itself, for example
>
>void x() {
> start = ClockCycles();
>...
> end = ClockCycles();
> time = end-start;
>}
>
>Now if Thread where x is running gets preempted time would be wrong.
>How can I know that? Any handlers I can install inside my app?
>Any other "time" related calls I can make instead, that
>returns thread running time (or process time) instead of absolute time?
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16202
>
>
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
|
|
|
Hans-Peter Reichert
|
Re: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:17 AM
post16211
|
Re: AW: How to know that thread is preempted?
we do it like this for our self made (sometimes sneaky) tools:
myClockId = ClockId(getpid(), pthread_self());
// check the id
rc = ClockTime(myClockId, 0, &timeStart);
//check rc
... do the stuff to measure ...
rc = ClockTime(myClockId, 0, &timeEnd);
//check rc
cpuNanos = (timeEnd - timeStart);
|
|
|
Colin Burgess(deleted)
|
Re: AW: How to know that thread is preempted?
|
Colin Burgess(deleted)
11/07/2008 11:22 AM
post16212
|
Re: AW: How to know that thread is preempted?
Yes, but ClockTime doesn't give you the same resolution as ClockCycles() - since it uses the OS accounting which is
coarse grained.
Elena you will have to attach to the THRUNNING event handler I think
Hans-Peter Reichert wrote:
> we do it like this for our self made (sometimes sneaky) tools:
>
> myClockId = ClockId(getpid(), pthread_self());
> // check the id
>
> rc = ClockTime(myClockId, 0, &timeStart);
> //check rc
>
> ... do the stuff to measure ...
>
>
> rc = ClockTime(myClockId, 0, &timeEnd);
> //check rc
>
> cpuNanos = (timeEnd - timeStart);
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post16211
>
--
cburgess@qnx.com
|
|
|
Brian Stecher
|
Re: AW: How to know that thread is preempted?
|
Brian Stecher
11/07/2008 11:27 AM
post16213
|
Re: AW: How to know that thread is preempted?
A gotcha with ClockCycles() is that you have to deal with CPU migration
on SMP - the values aren't necessarily synchronized between CPU's.
Brian
On Fri, Nov 07, 2008 at 11:22:51AM -0500, Colin Burgess wrote:
> Yes, but ClockTime doesn't give you the same resolution as ClockCycles() - since it uses the OS accounting which is
coarse grained.
>
> Elena you will have to attach to the THRUNNING event handler I think
>
> Hans-Peter Reichert wrote:
> > we do it like this for our self made (sometimes sneaky) tools:
> >
> > myClockId = ClockId(getpid(), pthread_self());
> > // check the id
> >
> > rc = ClockTime(myClockId, 0, &timeStart);
> > //check rc
> >
> > ... do the stuff to measure ...
> >
> >
> > rc = ClockTime(myClockId, 0, &timeEnd);
> > //check rc
> >
> > cpuNanos = (timeEnd - timeStart);
> >
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post16211
> >
>
> --
> cburgess@qnx.com
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post16212
>
--
Brian Stecher (bstecher@qnx.com) QNX Software Systems
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
|
|
|
Elena Laskavaia
|
Re: AW: How to know that thread is preempted?
|
Elena Laskavaia
11/07/2008 11:42 AM
post16216
|
Re: AW: How to know that thread is preempted?
Is it related to tracelogger? Would it work on non-instrumented kernel?
Colin Burgess wrote:
>
> Elena you will have to attach to the THRUNNING event handler I think
>
> H
|
|
|
Colin Burgess(deleted)
|
Re: AW: How to know that thread is preempted?
|
Colin Burgess(deleted)
11/07/2008 11:44 AM
post16219
|
Re: AW: How to know that thread is preempted?
No. I can't think of a way to determine that you have been preempted on a non instrumented kernel.
But who would be foolish enough to run that? ;-)
Colin
Elena Laskavaia wrote:
> Is it related to tracelogger? Would it work on non-instrumented kernel?
>
> Colin Burgess wrote:
>
>> Elena you will have to attach to the THRUNNING event handler I think
>>
>> H
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post16216
>
--
cburgess@qnx.com
|
|
|
Hans-Peter Reichert
|
AW: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:46 AM
post16221
|
AW: AW: How to know that thread is preempted?
I know some ...
>-----Ursprüngliche Nachricht-----
>Von: Colin Burgess [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 17:44
>An: ostech-core_os
>Betreff: Re: AW: How to know that thread is preempted?
>
>No. I can't think of a way to determine that you have been
>preempted on a non instrumented kernel.
>
>But who would be foolish enough to run that? ;-)
>
>Colin
>
>Elena Laskavaia wrote:
>> Is it related to tracelogger? Would it work on
>non-instrumented kernel?
>>
>> Colin Burgess wrote:
>>
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> H
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post16216
>>
>
>--
>cburgess@qnx.com
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16219
>
>
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
|
|
|
Hans-Peter Reichert
|
AW: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:44 AM
post16220
|
AW: AW: How to know that thread is preempted?
no and no
dynamic event filtering does not need tracelogger
but it needs procnto-instr!
>-----Ursprüngliche Nachricht-----
>Von: Elena Laskavaia [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 17:43
>An: ostech-core_os
>Betreff: Re: AW: How to know that thread is preempted?
>
>Is it related to tracelogger? Would it work on non-instrumented kernel?
>
>Colin Burgess wrote:
>
>>
>> Elena you will have to attach to the THRUNNING event handler I think
>>
>> H
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16216
>
>
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
|
|
|
Hans-Peter Reichert
|
AW: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:48 AM
post16222
|
AW: AW: How to know that thread is preempted?
for the event filter solution:
how do you handle nested preemtions?
and how can you quantify the preemptions?
you only can do interrupt restricted things inside your event filter/handler.
So in best case you do something like this
call void foo()
log f_enter in file.ptrace
... do some work
yield to thread X, event handler is called
log f_yield (pid, tid) in file.ptrace
... do some work
yield to thread Y, event handler is called
log f_yield (pid, tid) in file.ptrace
yield back to original thread, event handler is called
... do more work
log f_exit in file.ptrace
but this could only be done if the used file.ptrace is accessable inside the dynamic event handler functions.
which is not the fact, cause it's a normal file.
So making this file accessable through kernel memory would make it.
/hp
>-----Ursprüngliche Nachricht-----
>Von: Colin Burgess [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 17:23
>An: ostech-core_os
>Betreff: Re: AW: How to know that thread is preempted?
>
>Yes, but ClockTime doesn't give you the same resolution as
>ClockCycles() - since it uses the OS accounting which is
>coarse grained.
>
>Elena you will have to attach to the THRUNNING event handler I think
>
>Hans-Peter Reichert wrote:
>> we do it like this for our self made (sometimes sneaky) tools:
>>
>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>
>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>
>> ... do the stuff to measure ...
>>
>>
>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>
>> cpuNanos = (timeEnd - timeStart);
>>
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post16211
>>
>
>--
>cburgess@qnx.com
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16212
>
>
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
|
|
|
Colin Burgess(deleted)
|
Re: AW: AW: How to know that thread is preempted?
|
Colin Burgess(deleted)
11/07/2008 11:54 AM
post16225
|
Re: AW: AW: How to know that thread is preempted?
Elena was not producing a log, she was measuring time spent.
The main thing that would have to change is that she would have to specify the times to count
in the event handler user data.
The event handler would maintain the time that we were READY so it could be subtracted from the elapsed ClockCycles()
time.
The way you are working below it would be better to use the SYSTEM function enter/exit codes like she does in her kernel
instrumentation based profiler. But she apparentely needs to add THRUNNING events into that too.
Colin
Hans-Peter Reichert wrote:
> for the event filter solution:
> how do you handle nested preemtions?
> and how can you quantify the preemptions?
> you only can do interrupt restricted things inside your event filter/handler.
> So in best case you do something like this
>
> call void foo()
> log f_enter in file.ptrace
> ... do some work
> yield to thread X, event handler is called
> log f_yield (pid, tid) in file.ptrace
> ... do some work
> yield to thread Y, event handler is called
> log f_yield (pid, tid) in file.ptrace
> yield back to original thread, event handler is called
> ... do more work
> log f_exit in file.ptrace
>
> but this could only be done if the used file.ptrace is accessable inside the dynamic event handler functions.
> which is not the fact, cause it's a normal file.
> So making this file accessable through kernel memory would make it.
>
> /hp
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Colin Burgess [mailto:community-noreply@qnx.com]
>> Gesendet: Freitag, 7. November 2008 17:23
>> An: ostech-core_os
>> Betreff: Re: AW: How to know that thread is preempted?
>>
>> Yes, but ClockTime doesn't give you the same resolution as
>> ClockCycles() - since it uses the OS accounting which is
>> coarse grained.
>>
>> Elena you will have to attach to the THRUNNING event handler I think
>>
>> Hans-Peter Reichert wrote:
>>> we do it like this for our self made (sometimes sneaky) tools:
>>>
>>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>>
>>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>>
>>> ... do the stuff to measure ...
>>>
>>>
>>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>>
>>> cpuNanos = (timeEnd - timeStart);
>>>
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post16211
>>>
>> --
>> cburgess@qnx.com
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post16212
>>
>>
>
> *******************************************
> Harman Becker Automotive Systems GmbH
> Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
> Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
> Local Court Mannheim: Register No. 361395
>
>
> *******************************************
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
>...
|
|
|
Hans-Peter Reichert
|
AW: AW: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 12:17 PM
post16228
|
AW: AW: AW: How to know that thread is preempted?
I think it's about the profiling that's done using -finstrument-functions *without* traclogger
and for this case we need the log file.
I think you don't need additional events for the tracelogger functions profiling, you already have all the events
you need to do the accounting on IDE side.
I don't like the way I work below, because it's a YATL (yet another tracelogger logger)
so why not use tracelogger instead with some filters set.
or .... dtrace
/hp
>-----Ursprüngliche Nachricht-----
>Von: Colin Burgess [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 17:54
>An: ostech-core_os
>Betreff: Re: AW: AW: How to know that thread is preempted?
>
>Elena was not producing a log, she was measuring time spent.
>
>The main thing that would have to change is that she would
>have to specify the times to count in the event handler user data.
>
>The event handler would maintain the time that we were READY
>so it could be subtracted from the elapsed ClockCycles() time.
>
>The way you are working below it would be better to use the
>SYSTEM function enter/exit codes like she does in her kernel
>instrumentation based profiler. But she apparentely needs to
>add THRUNNING events into that too.
>
>Colin
>
>Hans-Peter Reichert wrote:
>> for the event filter solution:
>> how do you handle nested preemtions?
>> and how can you quantify the preemptions?
>> you only can do interrupt restricted things inside your
>event filter/handler.
>> So in best case you do something like this
>>
>> call void foo()
>> log f_enter in file.ptrace
>> ... do some work
>> yield to thread X, event handler is called log f_yield (pid, tid) in
>> file.ptrace ... do some work yield to thread Y, event handler is
>> called log f_yield (pid, tid) in file.ptrace yield back to original
>> thread, event handler is called ... do more work log f_exit in
>> file.ptrace
>>
>> but this could only be done if the used file.ptrace is
>accessable inside the dynamic event handler functions.
>> which is not the fact, cause it's a normal file.
>> So making this file accessable through kernel memory would make it.
>>
>> /hp
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Gesendet: Freitag, 7. November 2008 17:23
>>> An: ostech-core_os
>>> Betreff: Re: AW: How to know that thread is preempted?
>>>
>>> Yes, but ClockTime doesn't give you the same resolution as
>>> ClockCycles() - since it uses the OS accounting which is coarse
>>> grained.
>>>
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> Hans-Peter Reichert wrote:
>>>> we do it like this for our self made (sometimes sneaky) tools:
>>>>
>>>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>>>
>>>> ... do the stuff to measure ...
>>>>
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>>>
>>>> cpuNanos = (timeEnd - timeStart);
>>>>
>>>>
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post16211
>>>>
>>> --
>>> cburgess@qnx.com
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post16212
>>>
>>>
>>
>>...
View Full Message
|
|
|
Elena Laskavaia
|
Re: AW: AW: How to know that thread is preempted?
|
Elena Laskavaia
11/07/2008 12:42 PM
post16231
|
Re: AW: AW: How to know that thread is preempted?
Thanks all for you suggestions!
If we go into details there are two scenarios:
- one is using instrumented kernel - right now we inject function enter/exit and
I think I can extract preemption event from the same log already.
- second is not using instrumented kernel and using "file" to log time spent (it is buffered, so it does not have to be
called from traceevent handler),
in this case I think I should use ClockTime as suggested earlier.
Colin Burgess wrote:
> Elena was not producing a log, she was measuring time spent.
>
> The main thing that would have to change is that she would have to specify the times to count
> in the event handler user data.
>
> The event handler would maintain the time that we were READY so it could be subtracted from the elapsed ClockCycles()
time.
>
> The way you are working below it would be better to use the SYSTEM function enter/exit codes like she does in her
kernel
> instrumentation based profiler. But she apparentely needs to add THRUNNING events into that too.
>
> Colin
>
> Hans-Peter Reichert wrote:
>> for the event filter solution:
>> how do you handle nested preemtions?
>> and how can you quantify the preemptions?
>> you only can do interrupt restricted things inside your event filter/handler.
>> So in best case you do something like this
>>
>> call void foo()
>> log f_enter in file.ptrace
>> ... do some work
>> yield to thread X, event handler is called
>> log f_yield (pid, tid) in file.ptrace
>> ... do some work
>> yield to thread Y, event handler is called
>> log f_yield (pid, tid) in file.ptrace
>> yield back to original thread, event handler is called
>> ... do more work
>> log f_exit in file.ptrace
>>
>> but this could only be done if the used file.ptrace is accessable inside the dynamic event handler functions.
>> which is not the fact, cause it's a normal file.
>> So making this file accessable through kernel memory would make it.
>>
>> /hp
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Gesendet: Freitag, 7. November 2008 17:23
>>> An: ostech-core_os
>>> Betreff: Re: AW: How to know that thread is preempted?
>>>
>>> Yes, but ClockTime doesn't give you the same resolution as
>>> ClockCycles() - since it uses the OS accounting which is
>>> coarse grained.
>>>
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> Hans-Peter Reichert wrote:
>>>> we do it like this for our self made (sometimes sneaky) tools:
>>>>
>>>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>>>
>>>> ... do the stuff to measure ...
>>>>
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>>>
>>>> cpuNanos = (timeEnd - timeStart);
>>>>
>>>>
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post16211
>>>>
>>> --
>>> cburgess@qnx.com
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post16212
>>>
>>>
>>
>> *******************************************
>> Harman Becker Automotive Systems GmbH
>> Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
>> Chairman of the Supervisory...
View Full Message
|
|
|
Elena Laskavaia
|
Re: AW: How to know that thread is preempted?
|
Elena Laskavaia
11/07/2008 11:40 AM
post16215
|
Re: AW: How to know that thread is preempted?
Hans-Peter Reichert wrote:
> we do it like this for our self made (sometimes sneaky) tools:
>
> myClockId = ClockId(getpid(), pthread_self());
> // check the id
This I have to call just ones per thread? and I can re-use it many times?
>
> rc = ClockTime(myClockId, 0, &timeStart);
> //check rc
>
> ... do the stuff to measure ...
>
>
> rc = ClockTime(myClockId, 0, &timeEnd);
> //check rc
>
> cpuNanos = (timeEnd - timeStart);
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post16211
>
|
|
|
Hans-Peter Reichert
|
AW: AW: How to know that thread is preempted?
|
Hans-Peter Reichert
11/07/2008 11:43 AM
post16218
|
AW: AW: How to know that thread is preempted?
yes, as long as this thread exists.
But Colins' and Brians' comments should also be remarked.
Is the resolution we get from ClockTime() goog enough?
>-----Ursprüngliche Nachricht-----
>Von: Elena Laskavaia [mailto:community-noreply@qnx.com]
>Gesendet: Freitag, 7. November 2008 17:40
>An: ostech-core_os
>Betreff: Re: AW: How to know that thread is preempted?
>
>
>
>Hans-Peter Reichert wrote:
>> we do it like this for our self made (sometimes sneaky) tools:
>>
>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>This I have to call just ones per thread? and I can re-use it
>many times?
>
>
>>
>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>
>> ... do the stuff to measure ...
>>
>>
>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>
>> cpuNanos = (timeEnd - timeStart);
>>
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post16211
>>
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16215
>
>
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
|
|
|
|