+ Added comments

This commit is contained in:
Jennifer Averett
2000-01-13 18:32:38 +00:00
parent d65c376845
commit 9c1c778d56
6 changed files with 92 additions and 16 deletions

View File

@@ -50,15 +50,26 @@ void _CORE_message_queue_Close(
unsigned32 status
)
{
/*
* This will flush blocked threads whether they were blocked on
* a send or receive.
*/
_Thread_queue_Flush(
&the_message_queue->Wait_queue,
remote_extract_callout,
status
);
/*
* This removes all messages from the pending message queue. Since
* we just flushed all waiting threads, we don't have to worry about
* the flush satisfying any blocked senders as a side-effect.
*/
if ( the_message_queue->number_of_pending_messages != 0 )
(void) _CORE_message_queue_Flush_support( the_message_queue );
else
_Thread_queue_Flush(
&the_message_queue->Wait_queue,
remote_extract_callout,
status
);
(void) _Workspace_Free( the_message_queue->message_buffers );

View File

@@ -33,8 +33,8 @@
*
* _CORE_message_queue_Flush
*
* This function flushes the message_queue's task wait queue. The number
* of messages flushed from the queue is returned.
* This function flushes the message_queue's pending message queue. The
* number of messages flushed from the queue is returned.
*
* Input parameters:
* the_message_queue - the message_queue to be flushed

View File

@@ -57,6 +57,33 @@ unsigned32 _CORE_message_queue_Flush_support(
Chain_Node *message_queue_last;
unsigned32 count;
/*
* Currently, RTEMS supports no API that has both flush and blocking
* sends. Thus, this routine assumes that there are no senders
* blocked waiting to send messages. In the event, that an API is
* added that can flush a message queue when threads are blocked
* waiting to send, there are two basic behaviors envisioned:
*
* (1) The thread queue of pending senders is a logical extension
* of the pending message queue. In this case, it should be
* flushed using the _Thread_queue_Flush() service with a status
* such as CORE_MESSAGE_QUEUE_SENDER_FLUSHED (which currently does
* not exist). This can be implemented without changing the "big-O"
* of the message flushing part of the routine.
*
* (2) Only the actual messages queued should be purged. In this case,
* the blocked sender threads must be allowed to send their messages.
* In this case, the implementation will be forced to individually
* dequeue the senders and queue their messages. This will force
* this routine to have "big O(n)" where n is the number of blocked
* senders. If there are more messages pending than senders blocked,
* then the existing flush code can be used to dispose of the remaining
* pending messages.
*
* For now, though, we are very happy to have a small routine with
* fixed execution time that only deals with pending messages.
*/
_ISR_Disable( level );
inactive_first = the_message_queue->Inactive_messages.first;
message_queue_first = the_message_queue->Pending_messages.first;

View File

@@ -50,15 +50,26 @@ void _CORE_message_queue_Close(
unsigned32 status
)
{
/*
* This will flush blocked threads whether they were blocked on
* a send or receive.
*/
_Thread_queue_Flush(
&the_message_queue->Wait_queue,
remote_extract_callout,
status
);
/*
* This removes all messages from the pending message queue. Since
* we just flushed all waiting threads, we don't have to worry about
* the flush satisfying any blocked senders as a side-effect.
*/
if ( the_message_queue->number_of_pending_messages != 0 )
(void) _CORE_message_queue_Flush_support( the_message_queue );
else
_Thread_queue_Flush(
&the_message_queue->Wait_queue,
remote_extract_callout,
status
);
(void) _Workspace_Free( the_message_queue->message_buffers );

View File

@@ -33,8 +33,8 @@
*
* _CORE_message_queue_Flush
*
* This function flushes the message_queue's task wait queue. The number
* of messages flushed from the queue is returned.
* This function flushes the message_queue's pending message queue. The
* number of messages flushed from the queue is returned.
*
* Input parameters:
* the_message_queue - the message_queue to be flushed

View File

@@ -57,6 +57,33 @@ unsigned32 _CORE_message_queue_Flush_support(
Chain_Node *message_queue_last;
unsigned32 count;
/*
* Currently, RTEMS supports no API that has both flush and blocking
* sends. Thus, this routine assumes that there are no senders
* blocked waiting to send messages. In the event, that an API is
* added that can flush a message queue when threads are blocked
* waiting to send, there are two basic behaviors envisioned:
*
* (1) The thread queue of pending senders is a logical extension
* of the pending message queue. In this case, it should be
* flushed using the _Thread_queue_Flush() service with a status
* such as CORE_MESSAGE_QUEUE_SENDER_FLUSHED (which currently does
* not exist). This can be implemented without changing the "big-O"
* of the message flushing part of the routine.
*
* (2) Only the actual messages queued should be purged. In this case,
* the blocked sender threads must be allowed to send their messages.
* In this case, the implementation will be forced to individually
* dequeue the senders and queue their messages. This will force
* this routine to have "big O(n)" where n is the number of blocked
* senders. If there are more messages pending than senders blocked,
* then the existing flush code can be used to dispose of the remaining
* pending messages.
*
* For now, though, we are very happy to have a small routine with
* fixed execution time that only deals with pending messages.
*/
_ISR_Disable( level );
inactive_first = the_message_queue->Inactive_messages.first;
message_queue_first = the_message_queue->Pending_messages.first;