Malloc() under UNICOS

[ethan miller]

In article <729 at garth.UUCP> fouts at bozeman.bozeman.ingr.UUCP (Martin Fouts) writes:
%>>>>> On 28 Aug 90 16:51:52 GMT, ttw at lanl.gov (Tony Warnock) said:
%
%Tony>      Generally, system actions such as MALLOC() cannot be speeded up.
%Tony>      These ususally require at least a trip through the operating
%Tony>      system. If the current location of the program in memory does not
%Tony>      have enough room for the program to expand, the job must be swapped
%Tony>      to disk and then put back into a larger slot.
%
%Malloc is not strictly a system operation, and doesn't always require
%a trip through the operating system.  The underlying system call is
%brk/sbrk, which adds memory to (subtracts memory from) the end of the
%data section of the program's address space.  malloc/free/realloc
%manage that memory once it has been allocated.

On the Y-MP, at least, there are *always* two traps to the operating
system.  The malloc() call must use semaphores to guard the allocation
routine, and manipulating them requires interrupts to be off so they
can be set and cleared atomically.  Because the interrupt mask can't
be changed at user level, there are two (undoubtedly very short)
traps to the system (it may be four--two to set and two to clear, but
I don't remember, though I can check).

This is in addition to any calls to brk() or sbrk().

ethan
=================================
ethan miller--cs grad student   elm at sprite.berkeley.edu
#include <std/disclaimer.h>     {...}!ucbvax!sprite!elm
Witty signature line condemned due to major quake damage.