What exactly are unmanaged resources?

Question

I want to know about unmanaged resources. Can anyone please give me a basic idea?

Xuthus

Also see this page, which gives a fantastic explanation and pattern for the proper usage of IDisposable, and how to take unmanaged resources into account: #538560 – Clint

Answer 1

Managed resources basically means "managed memory" that is managed by the garbage collector. When you no longer have any references to a managed object (which uses managed memory), the garbage collector will (eventually) release that memory for you.

Unmanaged resources are then everything that the garbage collector does not know about. For example:

• Open files
• Open network connections
• Unmanaged memory
• In XNA: vertex buffers, index buffers, textures, etc.

Normally you want to release those unmanaged resources before you lose all the references you have to the object managing them. You do this by calling Dispose on that object, or (in C#) using the using statement which will handle calling Dispose for you.

If you neglect to Dispose of your unmanaged resources correctly, the garbage collector will eventually handle it for you when the object containing that resource is garbage collected (this is "finalization"). But because the garbage collector doesn't know about the unmanaged resources, it can't tell how badly it needs to release them - so it's possible for your program to perform poorly or run out of resources entirely.

If you implement a class yourself that handles unmanaged resources, it is up to you to implement Dispose and Finalize correctly.

Retardment

Open Database connection comes under which category? Managed / Unmanaged? – Xuthus

+1 Other answers miss the important point that you are calling Dispose on a managed object that internally handles the freeing up of the unmanaged resource it wraps (e.g. file handle, GDI+ bitmap, ...) and that if you access unmanaged resources directly (PInvoke etc.) you need to handle that. – Topotype

@Dev: Unmanaged - as the GC doesn't know about it (assuming you are not using some hypothetical in-managed-memory database). But the connection object itself might not hold an unmanaged resource. Presumably the database connection uses an open file or network connection somewhere - but it is possible that another object (other than the connection object) is handling that unmanaged resource (perhaps your database library caches connections). Check the documentation and see where it asks you to call Dispose or use using. – Retardment

I have a basic comment/question on this, can I relate an object as managed/un-managed just by the type, for example, string is managed, DataSet is un-managed (which is why it has a Dispose() method), Database connections are un-managed (because they have dispose), etc. So is the assumption, if it has a "Dispose()" method, then it's un-managed? In addition to that, what would an XmlDocument object be? Thanks – Dimidiate

@Dimidiate That is a good rule of thumb. Although be mindful that all C# class instances are managed objects. If an instance of a class could hold unmanaged resources, then that class should implement IDisposable. If a class does implement IDisposable, then you should dispose of instances of that class with using or Dispose() when you are done with them. Based on this, your converse holds: If a class implements IDisposable, then it probably holds unmanaged resources internally. – Retardment

@ganders: I would read this question: #913728 – Laritalariviere

Also note that managed ressources often have small classes in .NET - a FILE is HEAVY, but the FileStream is not a lot more than a small management class. So, you open a ton and the GC never runs - but the S is crapping out. – Roughish

What "open files" actually mean? And isn't a database connection simply a (very lightweight) string? – Dearr

Answer 2

Some users rank open files, db connections, allocated memory, bitmaps, file streams etc. among managed resources, others among unmanaged. So are they managed or unmanaged?

My opinion is, that the response is more complex: When you open file in .NET, you probably use some built-in .NET class System.IO.File, FileStream or something else. Because it is a normal .NET class, it is managed. But it is a wrapper, which inside does the "dirty work" (communicates with the operating system using Win32 dlls, calling low level functions or even assembler instructions) which really open the file. And this is, what .NET doesn't know about, unmanaged. But you perhaps can open the file by yourself using assembler instructions and bypass .NET file functions. Then the handle and the open file are unmanaged resources.

The same with the DB: If you use some DB assembly, you have classes like DbConnection etc., they are known to .NET and managed. But they wrap the "dirty work", which is unmanaged (allocate memory on server, establish connection with it, ...). If you don't use this wrapper class and open some network socket by yourself and communicate with your own strange database using some commands, it is unmanaged.

These wrapper classes (File, DbConnection etc.) are managed, but they inside use unmanaged resources the same way like you, if you don't use the wrappers and do the "dirty work" by yourself. And therefore these wrappers DO implement Dispose/Finalize patterns. It is their responsibility to allow programmer to release unmanaged resources when the wrapper is not needed anymore, and to release them when the wrapper is garbage collected. The wrapper will be correctly garbage collected by garbage collector, but the unmanaged resources inside will be collected by using the Dispose/Finalize pattern.

If you don't use built-in .NET or 3rd party wrapper classes and open files by some assembler instructions etc. in your class, these open files are unmanaged and you MUST implement dispose/finalise pattern. If you don't, there will be memory leak, forever locked resource etc. even when you don't use it anymore (file operation complete) or even after you application terminates.

But your responsibility is also when using these wrappers. For those, which implement dispose/finalise (you recognize them, that they implement IDisposable), implement also your dispose/finalise pattern and Dispose even these wrappers or give them signal to release their unmanaged resources. If you don't, the resources will be after some indefinite time released, but it is clean to release it immediately (close the file immediately and not leaving it open and blocked for random several minutes/hours). So in your class's Dispose method you call Dispose methods of all your used wrappers.

Axiomatic

Good one on the additional clarity on unmanaged vs managed resources – Vichy

thx for your answer. which classes is it recommended that we actually call Dispose on? – Talishatalisman

This is simple. On each class which you use, you must verify, whether it implements IDisposable interface. If yes, then if you use such class in one method (eg: opening file, storing text, closing the file), you can use that using() { } pattern, which calls Dispose for you automatically. If you use such class in more methods (eg: your class contains File, in constructor it opens the file, then several methods add some logs...), then you must implement IDisposable interface by your class, implement the Dispose/Finalize pattern and properly dispose object of that class. – Merl

"...some built-in .NET class System.IO.File, FileStream or something else. Because it is a normal .NET class, it is managed." With respect, this is wrong and misleading. They are not managed. If they were managed, then you could allocate these classes and expect the garbage collector to fully handle deallocation of all resources in a deterministic fashion. However, this will lead to file handles and unmanaged resources being locked and held for much longer than necessary because the garbage collector will not deallocate the class, and not finalize it for potentially a very long time. – Consumable

It is true eventually the garbage collector will deallocate a FileStream class and call Finalize to free file handles, it will do so when memory is needed, which could be a very long time after the reference is needed, locking the file. This is why you shouldn't call these managed resources, because it implies the memory manager will properly handle them. They are unmanaged, they implement IDisposable, and you need to call Dispose or use a using block to ensure deterministic deallocation. – Consumable

No, it is not misleading and you didn't read it carefully. The classes itself are managed. They will be properly garbage collected. If you lose reference to FileStream, it will be garbage collected. But they contain unmanaged resources inside and because of that they must implement Dispose/finalise pattern and to release their unmanaged resources. Then the whole class can be said to be managed. – Merl

@Martas "They will be properly garbage collected. If you lose reference to FileStream, it will be garbage collected." This is a common misuse of these classes. Yes the garbage collector will free the unmanaged resource, but in a very delayed way, because it will not deallocate until memory pressure requires it to, which could be a very long time. The behavior of an application written with your advice will be one that has many bugs where it locks files long after they are no longer needed, overloads the database with too many unneeded connections, etc. – Consumable

@Consumable this post was mostly about terminology, whether abstract words "FILE" or "DATABASE" without any specification, what is ment by it, are managed or unmanaged. You can read everywhere, that FILES are managed and the same number of times that FILES are unmanaged in other posts. So I introduced 2 types: Built in classes (Filestream etc.) and your own experiments with "assembler". – Merl

@Consumable I agree with behaviour you describe, that if the file is not disposed by programmer and left on GC, it blocks resources and it leads to bugs and is definitely wrong approach. If you read my post and comments, I explain it there and I force the programmer to Dispose it. – Merl

No it is not just terminology. The statement you just made ""They will be properly garbage collected. If you lose reference to FileStream, it will be garbage collected." exemplifies the problem. Anyone who listens to you will rely on the garbage collector to deallocate these resources, and thus connections, file handles, and other unmanaged resources will be held for a nondeterministic amount of time causing potentially serious problems. This is absolutely wrong. You need to read some articles on deterministic deallocation. – Consumable

Let us continue this discussion in chat. – Merl

@Consumable in your comment you talked about "FileStream" by referring it to as unmanaged but its not, although internally it uses unmanaged resources to do its job.In the managed world, Microsoft has hidden a lot of unmanaged stuff from you by implementing the dispose pattern. Managed code doesn't mean it doesn't use unmanaged resources. However, Microsoft has done a good job of implementing IDisposable on those types of objects. This is evidenced by the fact that it implements IDisposable. In respect to that evidence we should consider it a managed object. – Tertial

@MalikKhalil I understand all that. I never claimed "FileStream" was unmanaged. You've lost the context of the discussion. The original point is ""They will be properly garbage collected. If you lose reference to FileStream, it will be garbage collected." is a misleading statement. It implies that you can rely on the garbage collector to free up the underlying unmanaged resource. The problem is the garbage collector may not run for hours if there is no memory pressure. This means you will have connections, file handles, sockets, etc. open when you no longer need them. – Consumable

@MalikKhalil "Microsoft has done a good job of implementing IDisposable on those types of objects." and MS says must to dispose of an object deterministically if it implements IDisposoable: "The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams." – Consumable

All that matters is you must explicitly dispose IDisposable objects, don't wait for the garbage collector: "If your app simply uses an object that implements the IDisposable interface, you should call the object's IDisposable.Dispose implementation when you are finished using it. Depending on your programming language, you can do this in one of two ways" learn.microsoft.com/en-us/dotnet/api/… – Consumable

Answer 3

Unmanaged resources are those that run outside the .NET runtime (CLR)(aka non-.NET code.) For example, a call to a DLL in the Win32 API, or a call to a .dll written in C++.

Impeditive

Answer 4

An "unmanaged resource" is not a thing, but a responsibility. If an object owns an unmanaged resource, that means that (1) some entity outside it has been manipulated in a way that may cause problems if not cleaned up, and (2) the object has the information necessary to perform such cleanup and is responsible for doing it.

Although many types of unmanaged resources are very strongly associated with various type of operating-system entities (files, GDI handles, allocated memory blocks, etc.) there is no single type of entity which is shared by all of them other than the responsibility of cleanup. Typically, if an object either has a responsibility to perform cleanup, it will have a Dispose method which instructs it to carry out all cleanup for which it is responsible.

In some cases, objects will make allowances for the possibility that they might be abandoned without anyone having called Dispose first. The GC allows objects to request notification that they've been abandoned (by calling a routine called Finalize), and objects may use this notification to perform cleanup themselves.

Terms like "managed resource" and "unmanaged resource" are, unfortunately, used by different people to mean different things; frankly think it's more useful to think in terms of objects as either not having any cleanup responsibility, having cleanup responsibility that will only be taken care of if Dispose is called, or having cleanup responsibility which should be taken care of via Dispose, but which can also be taken care of by Finalize.

Lobeline

Answer 5

The basic difference between a managed and unmanaged resource is that the garbage collector knows about all managed resources, at some point in time the GC will come along and clean up all the memory and resources associated with a managed object. The GC does not know about unmanaged resources, such as files, stream and handles, so if you do not clean them up explicitly in your code then you will end up with memory leaks and locked resources.

Stolen from here, feel free to read the entire post.

Joella

Answer 6

Any resource for which memory is allocated in the .NET managed heap is a Managed resource. CLR is completly aware of this sort of memory and will do everything to make sure that it doesn't go orphaned. Anything else is unmanaged. For example interoping with COM, might create objects in the proces memory space, but CLR will not take care of it. In this case the managed object that makes calls across the managed boundry should own the responsibility for anything beyond it.

Kermis

Answer 7

Let us first understand how VB6 or C++ programs (Non Dotnet applications) used to execute. We know that computers only understand machine level code. Machine level code is also called as native or binary code. So, when we execute a VB6 or C++ program, the respective language compiler, compiles the respective language source code into native code, which can then be understood by the underlying operating system and hardware.

Native code (Unmanaged Code) is specific (native) to the operating system on which it is generated. If you take this compiled native code and try to run on another operating system it will fail. So the problem with this style of program execution is that, it is not portable from one platform to another platform.

Let us now understand, how a .Net program executes. Using dotnet we can create different types of applications. A few of the common types of .NET applications include Web, Windows, Console and Mobile Applications. Irrespective of the type of the application, when you execute any .NET application the following happens

1. The .NET application gets compiled into Intermediate language (IL). IL is also referred as Common Intermediate language (CIL) and Microsoft Intermediate language (MSIL). Both .NET and non .NET applications generate an assembly. Assemblies have an extension of .DLL or .EXE. For example if you compile a windows or Console application, you get a .EXE, where as when we compile a web or Class library project we get a .DLL. The difference between a .NET and NON .NET assembly is that, DOTNET Assembly is in intermediate language format where as NON DOTNET assembly is in native code format.

2. NON DOTNET applications can run directly on top of the operating system, where as DOTNET applications run on top of a virtual environment called as Common Language Runtime (CLR). CLR contains a component called Just In-Time Compiler (JIT), which will convert the Intermediate language into native code which the underlying operating system can understand.

So, in .NET the application execution consists of 2 steps 1. Language compiler, compiles the Source Code into Intermediate Language (IL) 2. JIT compiler in CLR converts, the IL into native code which can then be run on the underlying operating system.

Since, a .NET assembly is in Intermedaite Language format and not native code, .NET assemblies are portable to any platform, as long as the target platform has the Common Language Runtime (CLR). The target platform's CLR converts the Intermedaite Language into native code that the underlying operating system can understand. Intermediate Languge is also called as managed code. This is because CLR manages the code that runs inside it. For example, in a VB6 program, the developer is responsible for de-allocating the memory consumed by an object. If a programmer forgets to de-allocate memory, we may run into hard to detecct out of memory exceptions. On the other hand a .NET programmer need not worry about de-allocating the memory consumed by an object. Automatic memory management, also known as grabage collection is provided by CLR. Apart, from garbage collection, there are several other benefits provided by the CLR, which we will discuss in a later session. Since, CLR is managing and executing the Intermediate Language, it (IL) is also called as managed code.

.NET supports different programming languages like C#, VB, J#, and C++. C#, VB, and J# can only generate managed code (IL), where as C++ can generate both managed code (IL) and un-managed code (Native code).

The native code is not stored permanently anywhere, after we close the program the native code is thrown awaya. When we execute the program again, the native code gets generated again.

.NET program is similar to java program execution. In java we have byte codes and JVM (Java Virtual Machine), where as in .NET we Intermediate Language and CLR (Common Language Runtime)

This is provided from this link - He is a great tutor. http://csharp-video-tutorials.blogspot.in/2012/07/net-program-execution-part-1.html

Kauffman

Answer 8

Unmanaged and managed resources are based on application domain.

From my understanding, unmanaged resource is everything that is used to make connection to outside of your application domain. It could be HttpClient class that you resort to fetch data outside of your domain or a FileStream that helps you to read/write from/to a file.

we use Using block to dispose these kind of classes objects immediately after our work is done because GC in the first place care about inside the process resources not outside ones, although it will be disposed by the GC at the end.

Dispirit