Blogus Maximus

Chris -- I think the accepted approach is to just use Monitors/Locks to control access. In all my years of developing C# code, using 'volatile' is so extremely rare where locking is used instead. This is what most people (should) do in their singleton patterns...

Good to know.

One more question: I notice a lot of people set up a string object inside the singleton class and then use that for locking around instantiation. I don't entirely understand how that helps, unless locking that member effectively causes the entire class to lock. Is that what's happening?

There is no volatile equivalent in VB because VB is not an optimizing compiler. The volatile keyword in C/C++, Java, and C# instruct the compiler not to “optimize away” repeated access to a field. (This can be important when more than one thread can write to the field). Since there is no such optimization done in VB, the keyword is not needed. Consider the following code:
Public Class Class1
Private _data As Integer
Public Sub SomeSub()
If (_data = 0) Then
If (_data = 0) Then
Dim x As Integer = _data
End If
End If
End Sub
End Class
An optimizing compiler might notice that the repeated IF statements are redundant, and, either remove one of them or at least fail to reload the value of “_data” before making the second “if”. The VB compiler will never consider doing this. The c++/c#/Java compilers will (when optimization is turned on). Examine the IL code produced by the C# compiler in DEBUG and RELEASE modes (optimization turned ON and OFF), as well as the IL code produced by the VB compiler using ILDASM for more information.
The above example is trivial (and non-real), but I am sure you can apply it to the thread-safe singleton pattern that you are translating.
Typically, however, multi-threaded access to members is controlled using one of the synchronization primatives (like the lock statement in VB and C#).

"One more question: I notice a lot of people set up a string object inside the singleton class and then use that for locking around instantiation. I don't entirely understand how that helps, unless locking that member effectively causes the entire class to lock. Is that what's happening?"

Essentially -- that's it. First, you probably already know that Lock is syntactical sugar around a try / Monitor.Enter / finally / Monitor.Exit pattern, much like "using" encapsulates a Dispose call.

Entering a lock requires an object reference. It can be any object reference, but there are a few caveats. When the executing code tries to enter the protected code block, it will check if lock is already obtained on the object, and if not, it will place a lock on it and execute the protected code. It "knows" if there's a lock on the object by checking the object's syncblock on the heap. If another thread tries to execute the same section of code, it will see that the lock is already obtained, and by default, will wait forever until the first thread releases the lock.

This is why releasing the lock is so important (and why it's done in Lock implicitly) but using the Monitor objects explicitly gives you some benefits, like specifying timeouts.

You may have seen examples like this:

lock (this) {....}

In this case, it's grabbing a lock, using the instance of the class (remember, any object reference can be used). This is a bad practice, though, because presumably your class is exposed and allows consumers of your class to place locks on it as a reference -- this means we don't necessarily control all of the locking.

So, long answer to the short question is that the better approach is to simply create an object that is internal to the class, so only the class has access to it and can ensure you have complete control over how the lock is maintained. I've often done this by creating a class with a member like so:

private static Object Locker = new Object();

Then within that class, I always lock on "Locker" -- it serves no other purpose than to be the locking member. While you can use any other reference type member, I tend to think a dedicated object is a bit more transparent and readable ... it's also important that the reference is the same to all other class instances, so in my case, it's a static variable. Otherwise, if other instances happen to exist (not really in your case...) they'd all be able to get locks because their instance is the one being shared. That's also where lock(this) breaks down, since the class could presumably have many instantiations (like in an ASP.NET environment).

HTH!

What happened to my comment? I think I'm suffering the same fate as Andy :)

code conveter

Java to vb
vb to java
c to java