Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Version 2 and Version 3 of FAQ/AlgorithmicComplexity


Ignore:
Timestamp:
02/02/06 03:10:11 (18 years ago)
Author:
JoelSherrill
Comment:

/* POSIX API */ Add intro and update on POSIX timers fixes.

Legend:

Unmodified
Added
Removed
Modified
  • FAQ/AlgorithmicComplexity

    v2 v3  
    4343Although freeing memory is O(constant), freeing a large block of memory may result in the outstanding requests of multiple blocked tasks being satisfied.
    4444= POSIX API =
     45
     46The POSIX API inherits the following non-constant time algorithms from the SuperCode
     47
     48 *  Variable length message support
     49 *  Priority based message insertion
     50 *  Timer insertion (timer manager, delays, and timeouts)
    4551= Message Queue Manager =
    4652= mq_open =
     
    6167
    6268'''FIX:''' This is a bad implementation which was originally submitted by a user who did not understand the standard  pattern of object management.  This pattern requires objects be preallocated at system initialization time and object creation only removes one from an inactive object list.  Normally, RTEMS object Id to pointer translation is constant order so, this manager is fixable.
     69
     70'''UPDATE:''' As of 1 Feb 2006, JoelSherrill is testing a new implementation of POSIX timers which will not have O(n) object Id management.