Hi Ed,
On 3/19/2016 7:26 AM, Ed Prochak wrote:
As long as the free operation is atomic.
If the free also performed the coalesce of adjacent free blocks, you might need to keep the malloc at bay.
A lock on the free list (for atomicity) handles that.
I allow allocation requests to block *in* the allocator. I.e., "I'll
wait here UNTIL my request can be satisfied" (rather than spinning
trying to reissue a failed request).
This implies that other allocation requests should wait.
(you can argue this point for different allocator strategies but
the general idea should be obvious: if someone is waiting for a
resource, then *he* should get the resource before others who
may LATER want it).
But, you have to allow releases to continue else the blocking
allocate will never be satisfied! ("Nope, *still* not enough
free memory for me to satisfy my needs!")
So, you have two locks involved: one protects the free list
(so allocates and frees can behave atomically wrt that resource)
and another that is OPTIONALLY taken by an allocation request
that is "waiting for available resources". I.e., this second
lock is the "allocate lock" while the first lock is the
"memory manager lock".
My question has to do with the potential for needing a lock
governing "pending releases" -- beyond the lock used to govern access
to the free list itself.
[I.e., I can't envision any practical situation in which a *free*
could block "waiting" to be able to complete. Once *the* free list
is accessible (unlocked), the free() should be able to finish;
there are no potential "resource shortages" that need to be addressed
as there are in the allocate example.]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)