[Bug 1252] _Thread_queue_Dequeue_priority incomplete
rtems-bugs at rtems.org
rtems-bugs at rtems.org
Mon Aug 20 18:03:44 UTC 2007
http://www.rtems.org/bugzilla/show_bug.cgi?id=1252
joel.sherrill at oarcorp.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |minor
Component|cpukit |doc
------- Comment #1 from joel.sherrill at oarcorp.com 2007-08-20 13:03 -------
I can understand how you got to the conclusion this is incorrect behavior but
the suspend state is in ADDITION to the blocking states. Reading this:
http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.7.1/share/rtems/html/c_user/c_user00302.html
doesn't add anything.
"A blocked task may also be suspended. Therefore, both the suspension and the
blocking condition must be removed before the task becomes ready to run again."
http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.7.1/share/rtems/html/c_user/c_user00059.html
doesn't directly address this case. And neither do the suspend/resume manual
pages.
Suspension is in addition to blocking for a resource. The task can be given a
resource (e.g. mutex, semaphore, memory, message, etc.) and still remain unable
to execute. suspend/resume is a strictly manual control.
In this case, the behavior is completely expected and intended. I am going to
change this to a documentation bug of minor severity because it is the intended
behavior.
--
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
More information about the bugs
mailing list