PF> malloc/realloc/free (these can become an
PF> especially nasty bottleneck in a
PF> multithread program;

 GM>     Your above statement caught my eye. Could you elaborate a little?

What Peter means is that in a multithreaded program where several threads
are doing heap allocation/deallocation operations, the heap can become a
bottleneck.  Many threads can end up waiting around for a single thread to
finish using the heap.  This is because the heap is usually designed in
most C/C++ runtimes to be protected by a single mutex semaphore. What is
really bad about this is that it can cause priority inversion problems
where a high-priority thread can end up waiting for a low-priority thread
to finish using the heap.  I don't know if OS/2 detects priority inversions
and temporarily reprioritizes the low-priority thread to the same priority
as the high-priority thread until the low-priority thread is no longer
blocking the high-priority one, but some real-time operating systems such
as VxWorks do this.

This sort of heap bottleneck problem can royally screw over a real-time
system.  I know, because I've seen it happen to code I wrote.  I had to
spent a couple of weeks fixing it up to get rid of the problem by
preallocating sets of buffers and writing some functions to
allocate/deallocate out of these preallocated buffer sets.  With VisualAge
C++ 3.0, it might be possible to avoid this by using multiple user heaps. 
But at the time, I was using C Set++ 2.1 which didn't have such a feature.


--- Maximus/2 2.02