.Net Statics

[ASB]

Yes I follow everything said and Weltchys point about thread static.

But I still go back to what the documentation says:-

"If the procedure is not Shared, its local variables are instance variables, including the Static variables."

So, what my interpretation of this was is that it simply produced a member variable which was hidden from outside the method. It would be otherwise treated the same as any other instance variable. This is precisely what I wanted.

Clearly the documentation simply lies.

[Joe Black]

Because you don't understand threading and the nature of Static data. Like most VB6 to VB.NET people.

Perhaps. My take on it though is that he understands what it should do, and that the underlying VB.NET and CLR implementation does an unexpected hack which isn't capable of achieving what it should.

Think outside the box...

"In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread."

See above.

[Weltchy]

In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread. If the thread re-enters the method it will be able to pick up it's own stored state, and any other thread would have it's own individual state.

Sounds about right. Just be careful if your using it within ASP.NET, as the thread you pickup will be different whenever you repost. However, if its a service component or winform, your fairly [thread]safe

[Cowboy Bob]

Fair comment, but there are of course differing views.

In this particular case the method has to retain state. Now I can retain it as a member in the class for example. However the issue with that is scope.

Since it is only valid within the context of the method then I would prefer to reduce visibility to that method. If it's a member variable it's all too easy for somebody to come along and misuse it at a later date. Hence the thought of the static. Something I know you cannot do in C# (or couldn't).

In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread. If the thread re-enters the method it will be able to pick up it's own stored state, and any other thread would have it's own individual state.

[kirk]

I have a black car

[ASB]

Look at the ThreadStatic attribute as well, just in case you really want to hear that nice ka-plonking sound

Sorry, you've lost me.

I'm not using the attribute, or is VB being "helpful" and marking it for me. ??

[Weltchy]

Look at the ThreadStatic attribute as well, just in case you really want to hear that nice ka-plonking sound

[ASB]

Yes but...

That is referring to static members within shared (static) methods. Not instance methods. Here I have an instance method.

The MS documentation specifically describes them as instance variables in this case:

"If the procedure is not Shared, its local variables are instance variables, including the Static variables."

So it *should* have been alright. If I can get round to it then I'll reproduce it and look at the IL (or more likely just avoid them like the plague).

So my threading problem (and yes the exception is raised by Monitor.Enter) was not because of any lack of understanding on my part. Just by MS lieing in the docs.

As for C# I have a plan. But it doesn't seems to be getting any closer.

[DimPrawn]

Taking the piss is much more fun than helping people.

Anyway. Static in VB.NET is some syntactic sugar to generate a hidden Shared (static in C#) class level variable in the IL to simulate a local static variable. Sounds like a typical VB.NET kludge to me and trap for the unwary.

This Blog entry describes how the static local variable is intitialised and the impact of multiple threads.

http://weblogs.asp.net/psteele/pages/7717.aspx


Now since you have:

Protected Overrides Function DeviceHasBeenEnabled() As Boolean
Static blnFirstTime As Boolean = False

You are trying to combine an Instance method with a static field and I am guessing here (I do C#) that the behind the scenes kludge is designed to work with:

Shared Function DeviceHasBeenEnabled() As Boolean
Static blnFirstTime As Boolean = False


Lesson: Learn C#. Understand IL. Understand threading and initialisation.

HTH

[ASB]

Why the hell would you want to? Statics are for constants (which should be declared final) or (though personally I think it's bad practice) for use as member variables in static classes (ie singletons). That is it. Anything else is a threading disaster waiting to happen...

Fair comment, but there are of course differing views.

In this particular case the method has to retain state. Now I can retain it as a member in the class for example. However the issue with that is scope.

Since it is only valid within the context of the method then I would prefer to reduce visibility to that method. If it's a member variable it's all too easy for somebody to come along and misuse it at a later date. Hence the thought of the static. Something I know you cannot do in C# (or couldn't).

What I was curious of was what is the specific threading issue that causes the allocation to fail, because clearly there is something I misunderstood. Perhaps DP will enlighten me rather than just taking the piss.

[ASB]

Because you don't understand threading and the nature of Static data. Like most VB6 to VB.NET people.

Maybe, maybe not. But don't you think that might have been part of the reason for the question?

Would you care to enlighten me O great one.

[Cowboy Bob]

Obviously I can do it a different way with no problems but why the hell can't I allocate a static in this circumstance.

Why the hell would you want to? Statics are for constants (which should be declared final) or (though personally I think it's bad practice) for use as member variables in static classes (ie singletons). That is it. Anything else is a threading disaster waiting to happen...

[DimPrawn]

Because you don't understand threading and the nature of Static data. Like most VB6 to VB.NET people.

[ASB]

Protected Overrides Function DeviceHasBeenEnabled() As Boolean
Static blnFirstTime As Boolean = False


The above code throws a null reference exception.

I am guessing it's because the ultimate caller is in a SyncLock ??

Obviously I can do it a different way with no problems but why the hell can't I allocate a static in this circumstance.