[Openib-windows] Reference count as a solution to the problem of an object life ti me

[Tzachi Dar]

This mail discusses the method of “reference count” as a solution to the
problem of the object life time problem. This is actually a proposal to
where we should try and reach in the future of our stack.
 
Simply speaking, the problem of object life time is how to delete it on the
right time. We have to note that if we fail to allocate an object at all,
this means that we have some memory leak. If a program continues leaking
memory, eventually the system will run out of memory. The fact that this
doesn’t happen immediately makes it even harder to spot this type of
problem. For server side programs this behavior is not acceptable. On the
other hand, if we remove the object from memory, and than use this memory
(for example by some other thread, or by some call back) a different kind of
problem will be introduced. If we are lucky, an immediate access violation
exception will be thrown (we are “lucky”, since we know that we have a
problem with this object), if not that lucky, our memory will be corrupted,
and we will find the problems latter (much harder to debug). 
 
One approach to solve this problem is to have a “per problem” logic that
solves it. For example, if our object is a “connection” that holds some kind
of “ports” (the ports might start operations that eventually do call backs
on the connection), and is being hold by a session (that might call the
connection) then we should have a counter of the ports as well as some
information about calls that the session has called us. When the count of
ports drops to zero, and our state of the session is also “good” we might
delete the connection. Many flags are usually involved in holding
information about this logic (In shutdown, In error, waiting for completion
and so). 
The main problem of this approach is that it is very error pronoun. This
logic is usually complicated, and not documented well. More than this, any
change that is introduced to the code means also changes to this logic. As a
result races are being found out many times (usually just before a release).
When the shutdown of the connection starts because of a different reason
(for example a system/application is being shutdown) a new set of flags
should be introduced. Each change to the program logic also means changes to
the logic of the objects shutdown.
 
A different approach to solve this problem is garbage collection. It is
getting more and more popular today, especially due to the growing
popularity of managed code languages such as Java and C#. As the performance
of these languages is far from optimal, these languages (and actually
garbage collection) are not in the InfiniBand game.
 
This mail introduces a generic approach to solve this family of problems. As
the subject of this mail suggests this is the method of reference counting.
Reference counting is a very simple yet extremely effective mechanism for
managing objects lifetime in a multithreaded environment‎. It is used in
many programs and the most popular of them is probably in COM.
The big advantage of this method is that in each use of the object one
doesn’t have to think about the entire problem, rather it only has to think
of what he is doing with this object. Following a relatively simple set of
(per-function) rules ensures that the object is destroyed on the correct
place. The idea is similar to the idea of “the last person leaving the room
should turn the off the light”. Since the object is actually counting the
references to it, one should only tell the object when it starts using it
and when it has finished. Once finished, the object destroys it self. 
 
Each object should implement three methods: 1) AddRef (), 2) Release() and
3) DestructMe() (In C++ this is usually the destructor). Any one who uses an
object should call AddRef () before using the object, and call Release()
when he has finished working with the object. The object has an integer
filed that represents it reference count. The one who creates the object
creates it with a reference count of 1. When the reference goes down to 0
the DestructMe() function is called (implicitly) and the object is destroyed
and it’s memory is being released. This happens without the caller having
nothing to know about the object. 
 
In this page
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/com
_1vxv.asp
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/co
m_1vxv.asp>  there are explicit rules of when to call AddRef() and
Release(). 
 
Summery:
1)     When ever an object is being referenced by some threads, consider
seriously to use reference count.
2)     Many people have moved one step forward introducing automatic
pointers. This pointers do the AddRef and Release automatically, and
therefore the user doesn’t have to think about them at all. (As we are not
working in C++ this is currently not relevant).
3)     A good friend of mine used to say that if you don’t use reference
counting your program has a race (go find it!).
 
Thanks
Tzachi
 
 
 
 
 
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050914/0f619be6/attachment.html>