Use of mutex in destructors

[Rene Zwanenburg]

Since an OpenGL context is owned by one thread, any OpenGL calls 
made from other threads will fail. I've wrapped OpenGL 'objects' 
in D classes to automate destruction of the underlying object:

this() {
     // Init texture
}

~this() {
     glDeleteTextures(1, &_handle);
}

This will blow up if the GC runs in it's own thread. As a 
solution, I was planning for each wrapper instance to have a 
reference to an OpenGL command queue unique to the context which 
owns the object. This queue will be emptied once per frame. The 
texture wrapper will change to

this(CommandQueue comQueue) {
     this.comQueue = comQueue;
     comQueue ~= { /* Init texture */ }
}

~this() {
     this.comQueue ~= { /* Delete texture */ }
}

Putting the initialization in a command allows for asynchronous 
loading of resources, which is a nice bonus. However, access to 
this queue should be synchronized. I haven't used synchronized in 
D yet so I'd like to know what happens in the following situation:

One thread is processing the command queue. Due to some 
allocation by code in a command or on another thread, the GC 
runs. The processing thread still holds the lock on the queue 
mutex when the GC blocks all threads. The GC runs the destructor 
of a resource, so it waits for the lock on the queue to be 
released and we have a deadlock.

Does the GC somehow avoid this? If not, what's the best solution 
to this problem?