Allocation of objects

Joel Sherrill <joel@OARcorp.com> joel.sherrill at OARcorp.com
Thu May 19 13:51:15 UTC 2005


SAUDUBRAY, Fabien wrote:
> Thanks for your help ! 
> 
> I have still 2 questions :
> 1) I see in Changelog that why the Mega patch of 2002-07-01 "it appears that
> the name_table field is no longer needed."
> I try to find any usage of this name_table but it really seams that this
> table is not used.
> Yet the field remains and memory is still allocated for this fiels in
> _Objects_Extend_information. Why keeping an unused field and doing
> unnecessary job ?

Oversight.  A patch for 4.6 and the head is welcome.


> 2) Why keeping the Inactive_List mechanism in the unlimited case ? I means
> that in this unlimited case execution time for _Object_Allocate function is
> no longer determinist because it depends if the Inactive List is empty or
> not.

Correct.  What I think you are missing is that if you delete an object, 
it is placeed on the inactive list so it can be recycled.

FWIW some XXX_create are not fixed execution time anyway -- at leas task 
and message queue creation malloc memory for stacks/buffers.

> I mean that we could just allocate a new entry in the local_table field, and
> allocate the memory for one object control block.  

local_table is ONLY for valid active, open objects.  So once you delete 
it, we keep it on the inactive list until it is used again.

> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org] 
> Sent: Wednesday, May 18, 2005 2:41 PM
> To: SAUDUBRAY, Fabien
> Cc: 'rtems-users at rtems.com'
> Subject: Re: Allocation of objects
> 
> 
> SAUDUBRAY, Fabien wrote:
> 
>>I'm not sure of my understanding :
>>
>>Memory for objects is reserved, but is memory for objects  allocated 
>>during Initialization. (ie during _Objects_Initialize_information calls ?
> 
> )
> 
>>Because when we create an object (a task for example), the kernel calls 
>>the _Object_Allocate directive which returns the first object in the 
>>Inactive Chain of this kind of Object. But this implies that this Chain 
>>had been allocated before ?
>>
> 
> 
> Originally the configuration table defined the number of objects for 
> each type. The "unlimited" flag was introduced that allowed the number 
> of objects to grow.
> 
> A static number of objects gives a fixed deterministic time to create a 
> resource such as a task. The unlimited flag turns the configuration 
> table value into a block size. This lets you control the amount of 
> workspace overhead you get when the object table grows or shrinks. You 
> how-ever need to size the workspace to meet your needs.
> 
> You can find more details about the unlimited flag and sizing the 
> workspace here:
> 
> http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.6.2/share/rtems/html/c_
> user/c_user00386.html
> 
>   [ The auto-extending mode can .... ]
> 
> and a little about how it works here:
> 
>   http://www.rtems.org/ml/rtems-users/2005/april/msg00054.html
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------
> 
> CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.
> 
> SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.
> 
> 
> 
> This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.
> 
> If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.
> 
> ---------------------------------------------------------


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985




More information about the users mailing list