[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