Use of mutex in destructors

[Rene Zwanenburg]

On Friday, 27 April 2012 at 13:04:32 UTC, Dmitry Olshansky wrote:
> Don't. If I still worth anything in GL texture is bound to an 
> opaque uint of sorts. There is no problem copying this number 
> around.
> There is no point in holding multiple references to 42 ;) Just 
> copy the number.

That's correct. The problem is that if I copy the handle, I don't 
know when to release the texture. If the application was level 
based I could keep a list of all used resources for that level, 
and release them all when the level is destroyed. But an 
environment is usually quite large, so I need to support 
streaming. Handling destruction in the destructor end let the GC 
figure out the rest seemed like a nice solution :P.

> Use struct as reference-like type with some alias this magic 
> you may also gain interesting properties. This way you can hide 
> inside a delay-loading scheme of sorts.
> Say counting usage rates then once resource usage hits a margin 
> you go through the whole list or resources releasing those that 
> are rarely used.

I'm using something commonly known as an entity-component system. 
There are a lot of dependencies between entities and components, 
components and components owned by the same or another entity, 
and who knows what else ;). Using the GC there simplifies things 
a lot. Components containing reference counted OpenGL resources 
would still call the destructor on the GC thread. I _could_ 
modify the system to use ref counting everywhere, but I'm 
reluctant to do that.

Which reminds me, does the GC actually block all threads while 
calling the destructors on garbage? I'm far from an expert on 
GC's, but I believe the mark needs to stop the world, but the 
sweep can be done concurrently. If the GC thread calls 
destructors while the other threads aren't waiting, there 
shouldn't be a problem.

> Also let us not forget that each class instance holds monitor 
> object. Even though it's lazying initialized it still occupies 
> extra space.

That's good to keep in mind, but I'm not concerned about memory 
usage in this case. The size of a texture, vertex buffer or 
whatever dwarfs the size of the monitor. Total overhead should 
only be a few kilobytes.