#791 closed defect (fixed)
Returned period data "ticks_executed_since_last_period" incorrectly computed in RTEMS
Reported by: | jacques.seronie-vivien | Owned by: | Joel Sherrill |
---|---|---|---|
Priority: | normal | Milestone: | 2 |
Component: | score | Version: | 4.6 |
Severity: | major | Keywords: | |
Cc: | bugs@… | Blocked By: | |
Blocking: |
Description
According to chapter 19.4.6 of RTEMS C User Guide, in the DESCRIPTION section, the returned data "ticks_executed_since_last_period" from the directive "rtems_rate_monotonic_get_status" should indicate "how much processor time the owning task has consumed since the invocation of the rtems_rate_monotonic_period directive".
It is not what is really performed. This counter is incremented each time a tick occurs when the owning task is executing, which is fine, but also when the owning task preempts, which is not so fine. If the owning task preempts several time per tick during a rate monotonic period, the "ticks_executed_since_last_period" data will have a false value.
Release:
4.6.1
Environment:
build with solaris tools, sparc-rtems target, erc32 bsp
Attachments (1)
Change History (2)
comment:1 Changed on 09/01/05 at 13:23:00 by Joel Sherrill
Status: | assigned → closed |
---|
Changed on 12/03/06 at 13:31:13 by jacques.seronie-vivien
Attachment: | threaddispatch.c.diff added |
---|
threaddispatch.c.diff
State-Changed-From-To: open->closed
State-Changed-Why: We exchanged email discussing why I think this patch is not
appropriate but I wanted to make sure my rationale is in
GNATS. Neither having or not having this line of code
yields a completely accurate accounting. With the line in,
you do over count for thread which preempt frequently and
execute for very short time periods. With this line out,
there is a reasonable probability that threads which execute
for short lengths of time will never be executing when a
clock tick occurs so they will be shown as never having
executed.
I would hate to see threads which execute quickly get shown
as not having run at all.