Generally speaking, it's useful to decouple these troublesome objects from your UI thread entirely.

That model looks a bit more like an event or message driven model. Your UI would fire off an event requesting deletion, and the background thread would take care if it. You might wait for a confirmation message before removing the UI element (in case you want to display errors), or you might remove the UI element when the event is triggered and let generic error handling deal with exceptional circumstances. That will depend on the particulars of your app.

If another instance of the class can be created without completely shutting down the first and the instance being destroyed otherwise does not interact with program state, the solution is a trivial fire and forget. Fire off a background processing, log error via future or otherwise.

Resource pool

I assume, this is not the case for you. The likely scenario is when some resource is managed by a class and multiple instances can't manage the same resource. The destructor then has to be synchronized with constructor.

If this is the case, use a concept of resource pool. Instead of directly creating instances, request them from a pool/manager which is responsible for creating, disposing and caching of the resource. It can do the necessary synchronization too. Such pools often return handles/proxies instead of objects - this is a way to ensure that clients can not dispose the original object directly and have to coordinate with the pool.

For inspiration look how file handles are implemented in OS, or how DB connections are pooled, or how DI containers lazily create objects and reference-count them.