NDLI: Reclamation of memory for dynamic Ada tasking

Please wait, while we are loading the content...

Ada's impact: a quantitative assessment

GKS/Ada post mortem, a cost analysis

Empirical guidelines to use Ada effectively

Pioneering mission—critical Ada software

Experience with the automatic temporal analysis of multitasking Ada designs

Use of the Rational R1000 Ada development environment for an IBM based command and control system

The system-oriented editor—a tool for managing large software systems

Partitioned Ada libraries as a basis for variant control (extended abstract)

Developmental software configuration and integration in a large Ada project

Design automation for Ada development under DOD-STD-2167 (and beyond)

A life-cycle oriented Ada design language

An Ada graphical tool to support software development

Elementary functions packages for Ada

Linear algebra and other Ada packages adapted from HAL/S, FORTRAN, PL/I and MAC

Expert systems development in LISP and Ada

An Ada based approach to factory scale MAP network simulaton

Large system simulation using Ada

Discrete-event simulation in Ada

A low-level tasking package for Ada

An Ada distributed multiprocessor executive: from conceptualization to implementation

Self-organizing distributed operating system: implementation and problem using Ada

Real-time Ada demonstration

Ada programming techniques, research, and experiences on a fast control loop system

Ada applications on embedded targets

Storage reclamation models for Ada programs

Portable and efficient dynamic storage management in Ada

Reclamation of memory for dynamic Ada tasking

Using conceptual clustering for classifying reusable Ada code

A library of generic algorithms in Ada

Library structures for reusable components

Reclamation of memory for dynamic Ada tasking

Content Provider	ACM Digital Library
Author	Lefebvre, Philip J.
Abstract	While working on several large-scale Ada projects, I have found what I consider a major problem with the Ada Tasking mechanism, that is, the reclamation of memory allocated to a dynamic task after the task has been terminated. I have written my own utility package to specifically deallocate the memory assigned to any such task.The problem arises from the fact that dynamically created tasks are generated by the use of allocators. The Ada Language Reference Manual ( LRM ) states“An implementation must guarantee that any object created by the evaluation of an allocator remains allocated for as long as this object or one of its subcomponents is accessible directly or indirectly, that is, as long as it can be denoted by some name.”1This stipulation presents an interesting problem when applied to tasks. If the access type of a task is created within a library unit, memory allocated to execute this task will remain allocated for the entire span of the execution of program, even though the actual task object may have been terminated. Diagram 1 illustrates that memory is retained after a task is terminated.A more truly dynamic tasking model is needed in the Ada language. The model which is provided within the language does allow for the creation of tasks at runtime. This facility is useful when creating tasks that exist for the lifetime of the program, or for applications where memory management is not relevant. The problem with the current tasking model is that it does not allow a task, whose master is a library unit, to be created dynamically, to perform a specific action, and then to terminate and release all the memory reserved for the execution of the task.This failure to properly deallocate memory seems to be a problem inherent in the Ada language. It was at first believed that the algorithms used in Ada compilers to implement dynamic allocation of objects would enable them to perform sufficient garbage collection to improve management of the heap at runtime. This, however, did not prove to be the case. An optional Unchecked_Deallocation procedure was added to the standard predefined library units that may be delivered with an Ada development system. The Unchecked_Deallocation procedure does solve the problem of most storage reclamation, but the developers of the language did not allow memory allocated to dynamically created task objects to be reclaimed in a similar manner. The LRM states “If X designates a task object, the call FREE(X) has no effect on the task designated by the value of this task object.”2 I suspect that this specification was an attempt to prevent deallocating a currently active task.Because the language implementors are specifically prohibited from properly deallocating dynamic task memory, it is left to the individual Ada programmer to implement his or her own solution. For my solution I have identified two major functions which any algorithm attempting to solve this problem must address. First, the algorithm must have the ability to dynamically create tasks whose masters are blocks that can be exited, reclaiming the memory used to execute the tasks. Second, the algorithm must increase the scope of this task to areas outside of this block to allow task communication. This increase of scope must be done within the confines of the Ada Language so that the utility is portable.The concept behind the utility is the declaration of an access type of a task type within a block statement or a subprogram that can be exited after the completion of the task ( see diagram 2 ). I will refer to this block as the Master Block. Since the access type is declare inside the Master Block, any task that is created by an allocator of that access type ( referred to as the Dynamic Task ) will have the Master Block as its master. After the task is terminated, the block is exited and all the storage allocated to that task is reclaimed.Note that if the Environment Task ( the task that calls the main program ) were to call the Master Block, all other activity within the Environment Task would be suspended until the Dynamic Task completed. Upon completion, control would be released from the Master Block and given back to the Environment Task. The same effect would be exhibited by any other task calling the Master Block. Obviously, this reduction of execution to a fully sequential path is not acceptable; a second task must be created which can call the Master Block. I will refer to this task at the Base Task.Task communication can be accomplished by use of the Unchecked_Conversion utility ( see diagram 2 ). To provide visibility to the dynamically created task, the access type within the Master Block is not checked when converting it to an object of a second access task type who's master is the program unit. This point will be elaborated on in the task communication section.Several more complex questions remain in the description of the algorithm.How does the algorithm create more than one task?How does the algorithm determine when a task is terminated?How does the algorithm control access to the pointers to prevent access to deallocated storage?How does the algorithm allow for rendezvous with these tasks?These questions are addressed individually below.
Starting Page	199
Ending Page	207
Page Count	9
File Format	PDF
ISBN	0897912438
DOI	10.1145/317500.317527
Language	English
Publisher	Association for Computing Machinery (ACM)
Publisher Date	1987-12-08
Publisher Place	New York
Access Restriction	Subscribed
Content Type	Text
Resource Type	Article

Central Library (ISO-9001:2015 Certified)
Indian Institute of Technology Kharagpur
Kharagpur, West Bengal, India | PIN - 721302

See location in the Map
03222 282435
Mail: support@ndl.gov.in

Sl.	Authority	Responsibilities	Communication Details
1	Ministry of Education (GoI), Department of Higher Education	Sanctioning Authority	https://www.education.gov.in/ict-initiatives
2	Indian Institute of Technology Kharagpur	Host Institute of the Project: The host institute of the project is responsible for providing infrastructure support and hosting the project	https://www.iitkgp.ac.in
3	National Digital Library of India Office, Indian Institute of Technology Kharagpur	The administrative and infrastructural headquarters of the project	Dr. B. Sutradhar bsutra@ndl.gov.in
4	Project PI / Joint PI	Principal Investigator and Joint Principal Investigators of the project	Dr. B. Sutradhar bsutra@ndl.gov.in Prof. Saswat Chakrabarti will be added soon
5	Website/Portal (Helpdesk)	Queries regarding NDLI and its services	support@ndl.gov.in
6	Contents and Copyright Issues	Queries related to content curation and copyright issues	content@ndl.gov.in
7	National Digital Library of India Club (NDLI Club)	Queries related to NDLI Club formation, support, user awareness program, seminar/symposium, collaboration, social media, promotion, and outreach	clubsupport@ndl.gov.in
8	Digital Preservation Centre (DPC)	Assistance with digitizing and archiving copyright-free printed books	dpc@ndl.gov.in
9	IDR Setup or Support	Queries related to establishment and support of Institutional Digital Repository (IDR) and IDR workshops	idr@ndl.gov.in