A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » Processes
  • » Deallocating memory in multi-threaded environment.

#1 2011-04-29 08:45 AM


Deallocating memory in multi-threaded environment.

#2 2011-04-29 12:25 PM

From: Boston, MA
Registered: 2002-06-12
Posts: 3,839

Re: Deallocating memory in multi-threaded environment.

Yeah, if you're dealing with a dynamically allocated object which can go away at any time, you certainly don't want to put your lock inside it...  What you want the lock to protect is actually accessing the pointer to that object...  So, the lock needs to be outside, and be persistent (ie: not dynamically allocated and freed along with the object itself)...  That way, no one will ever dereference the pointer to the object at all unless they hold the lock...  In the case of removing the object, any other threads trying to aquire the lock after you've begun the removal process will see that the pointer to the object is now NULL once they finally do aquire the lock, so they'll know it has been removed...


#3 2011-04-30 11:02 AM

From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Deallocating memory in multi-threaded environment.

What you have to keep in mind is what a lock actually protects against.
If you have a structure lock, that lock protects against concurrent access
to the structure. It can only do lifetime management indirectly, such as
updating a reference count. But as Rob said, you need another lock to
serialize access to all the pointers leading to the structure. In your case,
you need to take another lock for any container modifications (I guess,
your code is a bit fuzzy. Normally you have some kind of list/tree or other
data structure to store all references to dynamic structures). When you
hold that lock AND the structure lock, it's safe to remove any references
to the structure and deallocate it.

So I guess what makes it hard is to try to do everything with one structure
lock, which is in the wrong place for this. If you don't have a container,
but a linked list with the next and previous pointers within the structure
itself, you can get away by taking the previous, current and next structure
locks (in a fixed order, to avoid deadlock) and update all the pointers and
deallocate safely, without introducing new locks. But it gets quite messy
when using too many wrapper containers like in your example code.


  • Index
  • » Processes
  • » Deallocating memory in multi-threaded environment.

Board footer

Powered by FluxBB