Wow that is a lot of questions, with a lot of possible answers:
1. In the pure sense of the words "memory leak" there should be no way for a
managed application to leak memory. Every object or data type you create is
tracked by the .Net environment (CLR) and will be destroyed and reclaimed at
an unspecified time, this is the job of the Garbage collector. It will
periodically go through the memory map looking for objects that are no longer
in scope or referenced in the code, therefore they cannot be accessed, and
can be destroyed, this is not determinitic to the application, it is when the
GC decides it needs to try to reclaim resources it will run (you could force
it using GC.Collect(), but I would not recommend that, the garbage collector
probably knows best when it wants to run).
It is entirely possible that you write code that uses resources such as
memory / file handles / db connections etc and you do not release them
properly, i.e. you somehow keep a reference to the object, so for the
lifetime of your application you will consuming more and more resources which
will look like a kind of memory leak and you keep creating more and more
instances of the object. Look into the IDispose interface and pattern it is
pretty interesting.
2. YES - unmanaged code is not governed by the CLR, you may allocate memory
and not deallocate it therefore causing a memory leak (using languages such
as C, C++), as you are outside of managed code the CLR will have no knowledge
of this and it will not be garbage collected.
3. ???
4. In general Syncronous processing means that the caller of a method will
wait until the method which has been called has completed executing before
the caller continues executing, so for example:
Function A()
{
//Time=0 : Function A is called
//Time=1 : Call Function B, A will not continue beyond this point
//until FunctionB has completed
FunctionB();
//Time=2minutes : FunctionA now reaches this point after waiting on
FunctionB
//to complete
}
Function B()
{
//some really long processing time i.e. 2 minutes
}
An asyncronous call will call a method but the caller will not wait until
the called method returns, it will continue immediately. One example of this
is the BeginRead method of FileStream, you can request to read a section of
data, but you do not have to be blocked waiting for the read to complete,
you can continue processing other things and eventually EndRead will be
called to alert you that the read has completed.
The general pattern is that sometimes a syncronous method will have
asyncronous counterparts called BeginXXX and EndXXX, i.e. BeginInvoke,
EndInvoke, BeginRead, EndRead
5. 6. 7. Jon Skeet has some really excellent articles on this, try:
http://www.yoda.arachsys.com/csharp/threads/winforms.shtml
Hope that helps
Mark.
