. .
So this is possible, but not very attractive. One of the fellows in our group actually implemented
this for a customer with a very specific problem. It worked well, but it was not at all generalizable.
Using Other Methods to Make malloc() More Concurrent
It is possible to assign a mutex to protect each piece of free storage and have threads skip over
those areas when locked. Although possible, this technique suffers from excessive complexity. It
also suffers from excessively fine-grained locking. [If malloc() has to lock a mutex for every
single node in the free list, it could easily spend more time doing the locking than looking for the
memory. We do exactly this in One Local Lock.]
A different approach to this problem is to build a static array of malloc areas to be shared by all
threads (Figure 12-3). Now a thread calling malloc() can check for an unlocked malloc area by
calling pthread_mutex_trylock() on the area's mutex. If held, the thread will simply check
the next area. The probability of more than a few malloc areas being locked is vanishingly small
for any vaguely normal program. This version of malloc() would be safe, fairly fast, and
relatively simple.
Figure 12-3. Threads Using an Array of malloc() Areas.
Search WWH :
Custom Search
Previous Page
Multithreaded Programming with JAVA - Topic Index
Next Page
Multithreaded Programming with JAVA - Bookmarks