I believe Verdix was the vendor Wesley may have been talking about.  At
least I know Verdix had similar issues early in their development.

Contrary to what is claimed, at the time malloc and free were NOT thread
safe.  Nor were they Ada task safe.  In those days there were no real
threads.

As a customer support engineer for Verdix (and the VP of customer support),
I provided two solutions to the problem.

First, I used Unix tools to rename the objects malloc and free to "malxxx"
and "fxxx".  I then wrote two Ada task safe wrappers ("malloc" and "free")
that mutex-protected the calls to "malxxx" and "fxxx".  That gave the
customer's a quick and dirty task-safe solution.

Second, because malloc and free were much SLOWER than desired, I wrote a
memory allocator/deallocator that did O(1) "constant time" coalescing as
blocks were freed.  The allocation was still "first fit", but with minimal
fragmentation, the solution worked for customers.  Later, another engineer
added "small size queues" and some additional complexity that I am not sure
was worth it.

I also looked into O(ln N) allocation and O(ln N) deallocation routines that
use balanced trees, but found the search unnecessary.  When programmers
wanted fast allocation of objects, they built their own "blocks" of fixed
size objects and used the Ada allocator only to allocate the blocks.

When Verdix merged with Rational, the Rational solution was adopted.  It has
a number of different optimized algorithms, all with coalescing, including
the ability to use (thread-safe) malloc and free (which does do coalescing
on most Unix systems, but not all).

Now that C has caught up to Ada (in regards to tasks/threads and thread-safe
routines), using malloc and free is often appropriate, though there are
faster solutions if one takes into account information available from an Ada
program (such as Storage_Pool or Size representation attributes).

Regards,
Steve
"Then, after a second or so, nothing continued to happen."
Steven Deller
Smooth Sailing LLC
[log in to unmask]
410 757 6924


> -----Original Message-----
> From: S. Ron Oliver [mailto:[log in to unmask]]
> Sent: Wednesday, August 22, 2001 7:19 AM
> To: [log in to unmask]
> Subject: Re: Garbage Colection - Was Re: Does GNAT Ada 95 provide
> garbage collector ?
>
>
> >When we complained to the vendor, they sent us a
> >package containing nothing but two pragmas.  By
> >withing that package into our main program, we
> >caused the linker to use malloc and free instead
> >of the vendor's run-time manager.
> >
> >
> >
> >Result: thread-safe, efficient, reliable, RM-compliant
> >memory management!  So why on earth did they do what
> >they did in the first place?
>
>
> Good question.  An interesting example of "simplistic"?  But then, one
> would need some statistics  on data element size
> requirements/trends over
> time to know for sure HOW simplistic.
>
> sro
>
>
> S. Ron Oliver, semi-retired professor of Computer Science and Computer
> Engineering.  www.csc.calpoly.edu/~sroliver
>
> caress Corporation is proud to be the U.S. representative for
> Top Graph'X,
> developers of high quality software components, using Ada.  For more
> information, check out www.topgraphx.com.
>