Ok, after some research, I've come up with some sample code to
demonstrate the issue I brought up in a previous thread regarding the
thread-safety of unmanaged singletons wrapped by managed singletons.
To recap, the basic problem is this:

In managed code, a static object is global to a particular AppDomain,
while in unmanaged code, a static object is global to the entire
process. In an environment such as ASP.NET, where multiple AppDomains
are used in a single process, this can create potential thread-safety
hazards. In particular, it is not sufficient to wrap a
(non-thread-safe) unmanaged singleton with a managed thread-safe
wrapper. The unmanaged singleton must be thread-safe to begin with, or
it is not safe to use from managed code in a multi-AppDomain host such
as ASP.NET.

The sample code is structured as a VS.NET solution with three
projects:
- UnsafeSingleton: A Managed C++ Class Library containing an unmanaged
singleton, GlobalCounter, and its managed wrapper, UnsafeSingleton.
- DriverApp: A C# console application that uses the MC++ class library
to increment the shared counter several times and output the results
to the console. Uncomment line 23 of DriverApp.cs to observe what
happens when GlobalCounter relies on UnsafeSingleton to protect it
from concurrent access.
- AppDomainRepro: A C# console application that creates numerous
application domains and executes DriverApp in each one on a new thread
using AppDomain.ExecuteAssembly.

If anybody wants to see the sample code, please e-mail me at
<anti-spam>c_kernel at hotmail dot com</anti-spam>.