• Lock on free()?

    From Don Y@21:1/5 to All on Thu Mar 17 14:52:27 2016
    Is there ever a scenario where a memory manager's "free()"
    (unallocate) might need to observe a lock preventing
    that action from completing (SOLELY from the standpoint
    of the memory manager itself -- ignoring the application's
    particular requirements)?

    [Ignoring, of course, the possibility of a concurrent
    operation using shared resources essential to that
    operation completing]

    I.e., locking the *allocate* function has merit -- but,
    requires free() to proceed unhindered (obviously).

    The only instances I can imagine would involve meeting
    timeliness guarantees (but, solve that by fixing the
    manager's implementation!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ed Prochak@21:1/5 to All on Sat Mar 19 07:26:33 2016
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Ed Prochak on Sat Mar 19 13:37:16 2016
    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)