#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)

threaddispatch.c.diff (365 bytes) - added by jacques.seronie-vivien on Dec 3, 2006 at 1:31:13 PM.
threaddispatch.c.diff

Download all attachments as: .zip

Change History (2)

comment:1 Changed on Sep 1, 2005 at 1:23:00 PM by Joel Sherrill

Status: assignedclosed

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.

Changed on Dec 3, 2006 at 1:31:13 PM by jacques.seronie-vivien

Attachment: threaddispatch.c.diff added

threaddispatch.c.diff

Note: See TracTickets for help on using tickets.