[Mono-devel-list] HasShutdownStarted race?

[Michi Henning]

>
> Finalizers are run by one thread, so once you are in one, no new objets
> will get finalized behind your back.
>
> However, I'm not sure if the spec promises that at all.

No, no such promise in the spec. In fact, some MS people are talking
about using more than one GC thread in future releases, and that
would be perfectly compliant with the spec.

> OTOH, HasShutdownStarted probably *could* change in the middle of the
> method. But it won't matter.

I think it does matter, at least in some cases. In my situation, I have
finalizers
that need to access other objects during finalization. Normally, that's no
problem: when one of those objects gets collected, the finalizer works just
fine. Except during shutdown, once System.Environment.Exit() has been
called. Because objects can be finalized in any order during shutdown,
the finalizer now can no longer safely call into other objects and has to
avoid doing that, hence the test for HasShutdownStarted. But, if
the condition can change halfway through the execution of a finalizer,
that's not very useful. And, because the GC runs asynchronously
to the rest of the program, I cannot guarantee that I won't call Exit()
while the GC is in the middle of some finalizer.

As long as there is only one GC thread, not a problem: even if the
condition changes halfway through the execution of a finalizer, that
finalizer will still successfully complete, and then HasShutdownStarted
becomes true for all the remaining finalizers. But, with multiple GC
threads, that's no longer the case.

What worries me is that the documentation makes no guarantee as
to when the condition can change. And, if I rely on HasShutdownStarted
as suggested by MS, it seems I run the risk of my code breaking on a
future .NET (or Mono) version.

Cheers,

Michi.