Centralized resource handling

[Nexus]

Hello,

I would like to ask the ones of you who use some kind of centralized resource management system in your projects/engines a few things. You probably have a manager who checks whether resources like sf::Image have already been loaded and permits access to them. But even if you don't use such a system and still have some ideas, just discuss!

1. Who owns the resource and is responsible of freeing it? The resource manager or the user?

2. How does the user eventually access the resources? Does the manager give back raw pointers? Shared pointers?

3. Do you find it important that a centralized manager has the full control, so that he can even force the release of resources that are in use? Or do resources have strong-reference semantics like shared_ptr, so that they can only be destroyed if no one refers to them?

The background is that in Thor, I plan to switch from thor::ResourcePtr to std::tr1::shared_ptr, because this smart pointer is widely known and can be used without a dependency to my Resources module. But I lose some flexibility by doing so, since I can no more track the users of a resource. What do you think about it?

[Groogy]

I got this manager: https://github.com/SFML/SFML/wiki/SourceSmartResourceManager

Which uses a kind of smart pointer on my handles. As long as there is a handle to the resource it will never be destroyed. But in the event that we reaches zero do not necessarily mean that the resource is destroyed. It fill only be free'd if the memory is needed.

The one who owns the resource in this case is the manager. The user get's a handle to the resource which is used for all access to it. I don't remember why but not even the handle have a direct pointer to the resource. And forcing release of resources... I don't see when that would be useful? Only time you want to free a resource is if you don't have enough memory?

[JAssange]

I made my own that heavily uses templates so it doesn't have separate LoadImage, LoadFont etc messages. The manager 'owns' the resources and won't destroy them unless DestroyResource is called with its handle and no other copies are in use.

[keyforge]

My resource manager is a template class, which I can make singletons that use it as an interface. Like ImageManager : public Singleton<ImageManager>, public ResourceManager<sf::Image>, etc, etc. It's worked well for my current project and I probably won't change it unless it later becomes an issue.

1. The Resource Manager, but the user still has an option to free the resource themselves...

2. I store a pointer to the resource in a vector. I'm not sure this is the best storage container. The resource manager type is each a singleton. Accessing a loaded image and binding it as a texture is as easy as
[code]ImageManager::GetInstance().GetResource(Key)->Bind();[code]

It returns a raw pointer, I should probably modify this though.

3. I don't allow releasing resources that are in use, as this will lead to a runtime error. The latter is the way to go in my opinion. I haven't implemented this though yet. I'll most likely use std::tr1::shared_ptr later.

Any criticism?

[MorleyDev]

I based my current project's manager on XNA's ContentManager. I've found it simple enough to use easily and flexible enough.

They're still stored as reference counted pointers, but the actual content's memory is free'd when unload is called.

You can Unload individual or by bulk, and the actual loading is handled by a loader service (Services are stored in a typeid->service map in the Game class) created by the driver being used.

Presently I have two implementations of that loader:

One that uses it's own storage and the resulting objects are managed inside it and therefore not really unloaded when Unload is called unless the reference counting of Content managers that are in charge of it goes down to 0. This one isn't thread-safe, obviously.

One that doesn't store the content in itself, so fresh copies are loaded by each content manager.

I actually prefer the second one.

Resources all inherit from a base Resource class and some rtti magic is done to ensure they are used in the correct circumstances (basically in Windows I hash the typeid for faster comparisons, whilst in Linux I just do a flat pointer comparison).

[Nexus]

Thanks for the answers!

But in the event that we reaches zero do not necessarily mean that the resource is destroyed. It fill only be free'd if the memory is needed.

Yes, I have a strategy to specify whether unused resources should be kept in memory (which is the default behavior).

The manager 'owns' the resources and won't destroy them unless DestroyResource is called with its handle and no other copies are in use.

How do you check whether other resources are in use? With reference counting?

I don't allow releasing resources that are in use, as this will lead to a runtime error. The latter is the way to go in my opinion.

Yes, I tend to do it like this. Most often, releasing unused resources isn't meaningful. It might just prevent leaks if a reference is held although unused, but that's rather a logic error.

But since you use raw pointers, I'd also like to ask you how you know whether a resource is still in use?

Resources all inherit from a base Resource class and some rtti magic is done to ensure they are used in the correct circumstances

What do you mean with "correct circumstances"? And the inheritance prevents you from using SFML resources like sf::Image directly, doesn't it? One of my goals is to put very few requirements on the resource classes, the managing is completely non-intrusive.

[MorleyDev]

Well I've sorta done it cheaply at the moment, Each content type has an operator()() function which returns a reference to the SFML object inside it. Not the cleanest way to do it...

I did consider diving inside SFML and fiddling, but decided against it.

Well if you try and get a pointer to an Audio resource, for example, but the key you pass is for an already loaded Image, it notices the GetType() value is not correct, logs an error, and returns a null resource.

[Nexus]

Okay.

From a user point of view, do you (all) find std::tr1::shared_ptr far more comfortable than a custom smart pointer like thor::ResourcePtr? Are the restrictions (no forced release, no tracking of references to resources) justified in your opinion?

[Nexus]

Any ideas and suggestions are welcome