Geeks With Blogs

News

Google My Blog

Catch me at: The List!


My InstallScript Utility Belt My Amazon Wishlist
My Standard Disclaimer


Archives
Chris G. Williams Beware: I mix tech and personal interests here.
As part of my quest to become a better developer, I've been reading more tech books (ok I'm trying to finish ONE tech book without lapsing into a coma, but I digress.)  The thing is, it's a Java book. Technically it's a design patterns book, but all the code is in Java, so call it what you want...

Anyway, in my polylingual travels, I've been converting all the code in the book to vb.net for fun and to make sure I actually get what I'm doing. So today I stumbled across the Java keyword Volatile. I understand (basically) what it does for Java, but I don't really grok how to relate it back to VB.NET.

*For those of you wanting to know, Embedded.com has a pretty good description of the Volatile keyword, which follows:

"volatile is a qualifier that is applied to a variable when it is declared. It tells the compiler that the value of the variable may change at any time-without any action being taken by the code the compiler finds nearby."

So my question is, what if anything is the vb.net equivalent, and is it, in fact, actually needed with .net.

Just so you have some context, I'm playing with the Singleton Pattern.  Most of the VB.NET examples I've seen on the web completely disregard thread safety for this pattern, opting to cover the much simpler, but not thread-safe, version of the pattern (which is little more than private constructor and public "getInstance" method.)

update: Further digging reveals that the Volatile keyword exists in C# as well, so there is obviously a need for it. This just reinforces my question as to what the corresponding VB.NET keyword (or pattern?) would be to handle this. Posted on Sunday, July 15, 2007 2:16 AM | Back to top


Comments on this post: conversion of thread safe code from java to vb.net

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
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...
Left by Brian on Jul 15, 2007 11:40 AM

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
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?
Left by Chris on Jul 15, 2007 1:12 PM

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
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#).
Left by Bill Tudor on Jul 15, 2007 3:51 PM

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
"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!
Left by Brian on Jul 15, 2007 5:00 PM

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
What happened to my comment? I think I'm suffering the same fate as Andy :)
Left by Tobin on Jul 18, 2007 8:51 PM

# re: conversion of thread safe code from java to vb.net
Requesting Gravatar...
code conveter

Java to vb
vb to java
c to java
Left by Rajavelu on Jan 09, 2009 3:27 AM

Your comment:
 (will show your gravatar)


Copyright © Chris G. Williams | Powered by: GeeksWithBlogs.net