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. >