Changeset 9c1c778d in rtems


Ignore:
Timestamp:
Jan 13, 2000, 6:32:38 PM (21 years ago)
Author:
Jennifer Averett <Jennifer.Averett@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
2cef977
Parents:
d65c3768
Message:

+ Added comments

Files:
6 edited

Legend:

Unmodified
Added
Removed
  • c/src/exec/score/src/coremsgclose.c

    rd65c3768 r9c1c778d  
    5151)
    5252{
     53
     54  /*
     55   *  This will flush blocked threads whether they were blocked on
     56   *  a send or receive.
     57   */
     58
     59  _Thread_queue_Flush(
     60    &the_message_queue->Wait_queue,
     61    remote_extract_callout,
     62    status
     63  );
     64
     65  /*
     66   *  This removes all messages from the pending message queue.  Since
     67   *  we just flushed all waiting threads, we don't have to worry about
     68   *  the flush satisfying any blocked senders as a side-effect.
     69   */
    5370 
    5471  if ( the_message_queue->number_of_pending_messages != 0 )
    5572    (void) _CORE_message_queue_Flush_support( the_message_queue );
    56   else
    57     _Thread_queue_Flush(
    58       &the_message_queue->Wait_queue,
    59       remote_extract_callout,
    60       status
    61     );
    6273
    6374  (void) _Workspace_Free( the_message_queue->message_buffers );
  • c/src/exec/score/src/coremsgflush.c

    rd65c3768 r9c1c778d  
    3434 *  _CORE_message_queue_Flush
    3535 *
    36  *  This function flushes the message_queue's task wait queue.  The number
    37  *  of messages flushed from the queue is returned.
     36 *  This function flushes the message_queue's pending message queue.  The
     37 *  number of messages flushed from the queue is returned.
    3838 *
    3939 *  Input parameters:
  • c/src/exec/score/src/coremsgflushsupp.c

    rd65c3768 r9c1c778d  
    5858  unsigned32  count;
    5959
     60  /*
     61   *  Currently, RTEMS supports no API that has both flush and blocking
     62   *  sends.  Thus, this routine assumes that there are no senders
     63   *  blocked waiting to send messages.  In the event, that an API is
     64   *  added that can flush a message queue when threads are blocked
     65   *  waiting to send, there are two basic behaviors envisioned:
     66   *
     67   *  (1) The thread queue of pending senders is a logical extension
     68   *  of the pending message queue.  In this case, it should be
     69   *  flushed using the _Thread_queue_Flush() service with a status
     70   *  such as CORE_MESSAGE_QUEUE_SENDER_FLUSHED (which currently does
     71   *  not exist).  This can be implemented without changing the "big-O"
     72   *  of the message flushing part of the routine.
     73   *
     74   *  (2) Only the actual messages queued should be purged.  In this case,
     75   *  the blocked sender threads must be allowed to send their messages.
     76   *  In this case, the implementation will be forced to individually
     77   *  dequeue the senders and queue their messages.  This will force
     78   *  this routine to have "big O(n)" where n is the number of blocked
     79   *  senders.  If there are more messages pending than senders blocked,
     80   *  then the existing flush code can be used to dispose of the remaining
     81   *  pending messages.
     82   *
     83   *  For now, though, we are very happy to have a small routine with
     84   *  fixed execution time that only deals with pending messages.
     85   */
     86
    6087  _ISR_Disable( level );
    6188    inactive_first      = the_message_queue->Inactive_messages.first;
  • cpukit/score/src/coremsgclose.c

    rd65c3768 r9c1c778d  
    5151)
    5252{
     53
     54  /*
     55   *  This will flush blocked threads whether they were blocked on
     56   *  a send or receive.
     57   */
     58
     59  _Thread_queue_Flush(
     60    &the_message_queue->Wait_queue,
     61    remote_extract_callout,
     62    status
     63  );
     64
     65  /*
     66   *  This removes all messages from the pending message queue.  Since
     67   *  we just flushed all waiting threads, we don't have to worry about
     68   *  the flush satisfying any blocked senders as a side-effect.
     69   */
    5370 
    5471  if ( the_message_queue->number_of_pending_messages != 0 )
    5572    (void) _CORE_message_queue_Flush_support( the_message_queue );
    56   else
    57     _Thread_queue_Flush(
    58       &the_message_queue->Wait_queue,
    59       remote_extract_callout,
    60       status
    61     );
    6273
    6374  (void) _Workspace_Free( the_message_queue->message_buffers );
  • cpukit/score/src/coremsgflush.c

    rd65c3768 r9c1c778d  
    3434 *  _CORE_message_queue_Flush
    3535 *
    36  *  This function flushes the message_queue's task wait queue.  The number
    37  *  of messages flushed from the queue is returned.
     36 *  This function flushes the message_queue's pending message queue.  The
     37 *  number of messages flushed from the queue is returned.
    3838 *
    3939 *  Input parameters:
  • cpukit/score/src/coremsgflushsupp.c

    rd65c3768 r9c1c778d  
    5858  unsigned32  count;
    5959
     60  /*
     61   *  Currently, RTEMS supports no API that has both flush and blocking
     62   *  sends.  Thus, this routine assumes that there are no senders
     63   *  blocked waiting to send messages.  In the event, that an API is
     64   *  added that can flush a message queue when threads are blocked
     65   *  waiting to send, there are two basic behaviors envisioned:
     66   *
     67   *  (1) The thread queue of pending senders is a logical extension
     68   *  of the pending message queue.  In this case, it should be
     69   *  flushed using the _Thread_queue_Flush() service with a status
     70   *  such as CORE_MESSAGE_QUEUE_SENDER_FLUSHED (which currently does
     71   *  not exist).  This can be implemented without changing the "big-O"
     72   *  of the message flushing part of the routine.
     73   *
     74   *  (2) Only the actual messages queued should be purged.  In this case,
     75   *  the blocked sender threads must be allowed to send their messages.
     76   *  In this case, the implementation will be forced to individually
     77   *  dequeue the senders and queue their messages.  This will force
     78   *  this routine to have "big O(n)" where n is the number of blocked
     79   *  senders.  If there are more messages pending than senders blocked,
     80   *  then the existing flush code can be used to dispose of the remaining
     81   *  pending messages.
     82   *
     83   *  For now, though, we are very happy to have a small routine with
     84   *  fixed execution time that only deals with pending messages.
     85   */
     86
    6087  _ISR_Disable( level );
    6188    inactive_first      = the_message_queue->Inactive_messages.first;
Note: See TracChangeset for help on using the changeset viewer.