Static methods and Thread safety - C# Discussion Boards

Re: Static methods and Thread safety [modified]

6-Mar-07 7:59

Anyone confirm this is thread safe please?

internal static List<string> GetList(string xmlString)
{
List<string> list = new List<string>();

BuildList(xmlString, list);
return list;
}

private static void BuildList(string xmlString, List<string> list)
{

string someXml = ModifyXml(xmlString);
list.Add(GetString(someXml));

if (GetBool(someXml))
BuildList(someXml, list);
}

Thanks much..

Leslie Sanford6-Mar-07 8:12

Leslie Sanford

6-Mar-07 8:12

Looks thread safe to me. All of the methods you're calling are static; no instance objects are involved. Looks reentrant. I think you're safe.

EDIT-> When I say "instance objects," I'm refering to objects that persist at the instance level of a class. That is to say that none of the objects that I see used in the static methods persist at that level. So it looks safe.

-- modified at 14:22 Tuesday 6th March, 2007

Abisodun6-Mar-07 8:22

6-Mar-07 8:22

Cool - thanx :>)

Abisodun6-Mar-07 9:08

6-Mar-07 9:08

I thought were clear - You meant no instance variable of the class as opposed to an instance declared local to the method.

Thanks.

Leslie Sanford6-Mar-07 9:42

Leslie Sanford

6-Mar-07 9:42

Abisodun wrote:
I thought were clear - You meant no instance variable of the class as opposed to an instance declared local to the method.

Exactly.

Abisodun7-Mar-07 2:02

7-Mar-07 2:02

Your statement's been bugging me now I realize why. This code will cause a compilation error:

class MyClass
{
internal string stringVariable = string.Empty;
internal static void MyFunction()
{
stringVariable += "a";
}
}

Did you mean static variable of the class?

Instance variable always refers to a non static variable.

i.e.
class MyClass
{
internal string stringVariable = string.Empty;
internal static void MyFunction()
{
MyClass myClass = new MyClass();
myClass.stringVariable += "a";
}
}

which should not be a problem in a static method of the same class.

Leslie Sanford7-Mar-07 4:39

Leslie Sanford

7-Mar-07 4:39

Abisodun wrote:
Did you mean static variable of the class?

Instance variable always refers to a non static variable.

Yeah, I should have just said that since the methods are static, it's thread safe. I confused the issue by mentioning instance objects. The instance variables of a class can't be accessed from a static method, so there was no need to bring them into the discussion.

The main thing to watch out for with static methods and thread safety are objects that are passed into the method. Something like this:

public static void DoSomething(SomeObject obj)
{
    obj.Change();
}

This isn't tread safe. The reason being that two threads could call this method at the same time (relatively speaking), and the "Change" method may be performing some thread unsafe operation. The example you gave in your original post didn't do this, so it's thread safe. But also, if an object is a class level variable, you still want to be careful:

public class MyClass
{
    private static SomeObject obj = new SomeObject();
 
    public static void DoSomething()
    {
        obj.Change();
    }
}

This isn't thread safe for the same reason the first example isn't thread safe.

In your original post, all of the objects that were used were created within the static method. This means that if two threads called the method at the same time, the objects each thread uses is unique to the thread. So your original example is thread safe.

Does this help? Hopefully, I haven't made it more confusing.

Abisodun7-Mar-07 5:57

Declaring Sql Server Variables in C# Using .Net Remoting

7-Mar-07 5:57

No it's been very helpful. I was really only concerned about "List<string> list" being passed between static methods and recursively. But each new call stack starting with GetList in the first example should have it's own instance of "List<string> list".

I appreciate your help.

sunny_days6-Mar-07 7:34

sunny_days

6-Mar-07 7:34

Hey All,

I'm trying to update a database using .Net remoting. I am using SQL server code that includes variables like the following: @StudentFirstName.

When I run the program and hit the update button, which contains the following code:

this.dgResults.DataSource = dbc.ExecuteQuery("UPDATE Student SET FirstName=@StudentFirstName,LastName=@StudentLastName,Address=@StudentAddress,Phone=@StudentPhone,GPA=@StudentGPA WHERE StudentID = @StudentID AND FirstName=@OriginalFirstName AND LastName=@OriginalLastName AND Address=@OriginalAddress AND Phone=@OriginalPhone AND GPA=@OriginalGPA");

dgResults.DataMember = "Results";

I get an error saying that @StudentFirstName must be declared. I am wondering how you declare @StudentFirstName in C# using .Net Remoting. Anyone got any ideas or answers?

Re: Declaring Sql Server Variables in C# Using .Net Remoting

kubben6-Mar-07 10:02

kubben

6-Mar-07 10:02

Since you are passing in a string into your ExecuteQuery, you really need the actual values that you want to update your student table with. So if you have parameters getting passed into this method say:
p_studentFirstName,
p_studentLastName,
p_studentAddress ...

Then your update would be:
this.dgResults.DataSource = dbc.ExecuteQuery("UPDATE Student SET FirstName="+p_studentFirstName+",LastName="+p_studentLastName+",Address="+p_studentAddress+...

Anyway, hope that helps.
Ben

Intellectual Property Protection BEYOND OBSFUCATION

mike montagne6-Mar-07 6:42

Re: Intellectual Property Protection BEYOND OBSFUCATION

6-Mar-07 6:42

I would like to hear about intellectual property protection issues experienced by .Net commercial product developers and users of commercial 3rd party products protected by applications such as .NET Reactor:

http://www.eziriz.com/[^]

I want impervious intellectual property protection and a perfect user experience. Can do?

Glen Harvy6-Mar-07 19:50

Re: Intellectual Property Protection BEYOND OBSFUCATION

6-Mar-07 19:50

I have been using .Net Reactor and can recommend it although at this stage I am not aware if anyone has been able to "defeat" it Smile | :)

I certainly haven't come accross any reports and I did a lot of googling and research before buying it.

One problem that I have come accross though is that .Net Reactor apparently doesn't work with 64bit encoding. I have had one user try to run a .Net Reactor program compiled with the All CPU flag enabled on a 64 bit XP system without any luck. Eziriz said it should work on 64 bit as a 32 bit program but it apparently doesn't. I have no way of testing or trying to get it to work as I don't have a 64 bit system.

If someone can get to my code after it has been through .Net Reactor then I should feel flattered that they have gone to the trouble of doing so Suspicious | :suss:

If I had heaps of money I probably would have gone with Xeno with all it's bells and whistles but I am very happy with .Net Reactor.

One funny thing though - when you use .Net Reactor I found that it seemed "to easy" to use and so fast compared to the others. A bit like "Surely it can't be that easy" Big Grin | :-D

Glen Harvy

mike montagne7-Mar-07 8:24

Re: Intellectual Property Protection BEYOND OBSFUCATION

7-Mar-07 8:24

Thanks so much, Glen.

Glen Harvy wrote:
I have had one user try to run a .Net Reactor program compiled with the All CPU flag enabled on a 64 bit XP system without any luck. Eziriz said it should work on 64 bit as a 32 bit program but it apparently doesn't.

Is it possible they have some level (.Net configuration, OS configuration, etc.) configured to run 64-bit only?

Glen Harvy wrote:
If someone can get to my code after it has been through .Net Reactor then I should feel flattered that they have gone to the trouble of doing so

Perhaps. But (unas Dylan said it) *if* "we have something to protect," it needs to be the other way around -- truly undefeatable.

The issue I have at the moment is with custom licensing, and handling the licensing scheme. I just don't find much information in the documentation as to custom features... handling additional fields... that sort of thing. Do you use the SDK for such purposes?

Glen Harvy wrote:
One funny thing though - when you use .Net Reactor I found that it seemed "to easy" to use and so fast compared to the others. A bit like "Surely it can't be that easy"

That's a pretty strong recommendation. I tried the trial issue and built a distributable in little time, but am left with some stupid questions. What is a bona fide test system, and how should we go about testing so as to determine everything is working as it should? What does the user have to do on their end to process the license?

In other words, what I am wanting to do is collect the CurrentUser name and email address to which the validated will be returned, and to process that in validation process. Does the user have to manually run HID.exe or what? I mean, is it just a matter of determining that HID.exe has to go and remain with your distributables?

Another issue is how much performance might be degraded (if at all), compared to obsfucation? There might not be much difference there, but if there is, I'd like to know about it.

Glen Harvy7-Mar-07 12:23

Re: Intellectual Property Protection BEYOND OBSFUCATION

7-Mar-07 12:23

mike montagne wrote:
The issue I have at the moment is with custom licensing, and handling the licensing scheme. I just don't find much information in the documentation as to custom features... handling additional fields... that sort of thing. Do you use the SDK for such purposes?

I am using 2.7.1.5 and have just visited their site and notice the newer version - which I shall look at shortly.

I agree - the documentation is poor and frankly after reading a fair bit of their competitor's help/manuals it left me wondering if their program would do what it claimed. If you boil it all down though, their competitors help/manuals need to be considerably thicker because they allow far more options/fine tuning. Having said that, that is also why their competitors programs take so much longer.

I tested out the licencing part of the package AFTER I had already incorporated my own into my program. I figured that providing my program couldn't be de-compiled then that was sufficient for me to use my own method of key generation/validation. I looked at the licencing SDK but didn't use it for that reason. My program is one that probably wouldn't be used by a "hacker", reports are hard-coded etc so that was good enough for me.

mike montagne wrote:
That's a pretty strong recommendation.

It is and I mean it Smile | :)

. Adding .dll's is easy and cuts down on distribution. As far as scrambling my code is concerned it's a breeze. I don't need all the bells and whistles and I don't need to convince a boss that loves to see confusing screens, multilayed and configurable levels, pick and chose which strings to obfuscate etc.

I don't think you can customise the licencing side of it very well at all (at least I didn't think so). It was/is one of the reasons I don't use their licencing module. I also don't like linking my program to a computer (and this may detract from your product sales). Having said that, geting a user to use HID.exe shouldn't be a problem. HID just identifies some hardware components and creates a code based on that hardware. HID is not used again unless the user makes a hardware change. I believe .Net Reactor checks the hardware itself and compares the supplied code if you have configured it to use hardware checking.

You shouldn't be issuing a key until after they have paid so running HID.exe and sending you the resultant code shouldn't be a problem. I haven't tried it but you could include HID in your distributable and have your own program run it and send you the code without any difficulty.

Performance should not be an issue at all. There must be some degredation but I haven't had any adverse comments nor have I noticed any degredation - except of course a minor unnoticable (to the user)delay at startup. It's so minor I couldn't really bother to measure it.

I'll have a look at Version 3 and let you know if I have any other comments to make.

Another point about the licencing module is you should check with whoever is going to collect the funds/issue the keys as to their requirements. If your doing it yourself then no worries Smile | :)

.

Let me know how you go - your the first person I know of that's actually using (or at least thinking) of using it. I have searched the net high and low for feedback etc without any luck.

Regards,

Glen Harvy

mike montagne7-Mar-07 13:20

Re: Intellectual Property Protection BEYOND OBSFUCATION

7-Mar-07 13:20

Wow. Thanks so much for so much to think about!

Glen Harvy wrote:
If you boil it all down though, their competitors help/manuals need to be considerably thicker because they allow far more options/fine tuning.

I think my needs are like yours. The intellectual property protection is a must have issue -- and the decision comes down to whether or not it will be cracked by people who will damage my market.

Glen Harvy wrote:
I also don't like linking my program to a computer (and this may detract from your product sales).

I'm interested in your thinking here. What I want to do is offer a basic license, with extra (multiple installations) extensions costing enough to cover processing costs with a small profit. In other words, a $50 product with $15 multiple installation extensions.

In my experience, people don't pay for things if they don't have to. But like you say, if *I* buy software, I want to be able to install it on multiple systems. Sometimes I'll take it with me. Most of the time I'll work on it at the office. My hope is to make those further installations formal, yet not an abuse of the client (like so many licenses are).

As to .NET Reactor, I'm waiting to hear back from Denis there. I haven't tried to decompile yet, but I am about to do that. I just finished testing of the output .dll (my product is a library), and it went fine, although, like you, I didn't test 64-bit (which may prove to be an issue).

I really don't know what's supposed to be functional in the trial version. Everything appears to be working fine as far as reproduced CIL is concerned. Not even a detectable slowdown. That's very good. However, in my NR project, I have set an Inbuild Evaluation period (15) and Inbuild Number of Uses (50), with Show Expiration Screen, Show Nag Screen, and Shutdown Process after Expiration all set to true. Yet whether I copy the output license file to my test directory or not, I'm not seeing an Expiration or Nag screen, nor is my process shut down without the license. That doesn't bode well, but I'm waiting on an answer as to whether that is supposed to work in the demo installation. He *did* write me earlier that I *would* be able to test locally -- whether that means these features are not enforced I don't know.

I don't know why he has the separate Lock Settings and License Manager tab. I had to manually set the License Manager tab information to match the Lock Settings information -- which was simply ignored (?).

I like to see these kinds of (simple) things work perfectly. I may still use the product (even anxiously), but it may end up being with the same caveats you have raised. I've asked a number of questions about custom licensing and the SDK. I just don't have those yet -- and like you probably, I hope to avoid programming down any dead ends there.

In the past, in Windows executables, I have used a licensing scheme which marks the system and which is practically tamper proof (efforts far exceed the potential benefits). That was custom coded.

You don't happen to know of any material/guidelines for doing that with .NET libraries do you? The issues are somewhat different, and it would be nice to have a launching point from which to custom develop my own system, versus relying on the NR SDK for that.

tia,

m

Glen Harvy7-Mar-07 14:17

7-Mar-07 14:17

Let's break this discussion into two sections - Obfuscation and Licencing.

Licencing:

From what I can tell the SDK allows you to customize the licence file but not much else. I don't see how any of those customizations can be practically used in determining whether your program works or not. I have not examined the SDK or made any use of it but it may be possible for your program to read the licence file and do something based on the content of that file.

You either accept the licencing options NR provides or you don't. BTW: In my testing, the licencing options did work and I was very impressed. I think you must be doing something wrong if it's not working for you Frown | :(

My program and it's licencing are linked to the Club's Name. The licence code is generated by the combination of the Club's name and a secret word hardcoded into my program. The 30 day trial period is also "hardcoded" into my program. If the local Womens Association Smile | :)

have a hacker with heaps of time and the knowledge then I guess I've lost a sale Hmmm | :|

.

My registration company is ShareIt and they generate the keys by using their key generator software which I have also NR'ed so the all important secret word is obfuscated even to them.

In your scenario I don't see how you can use the NR licencing module without using HID.exe.

Obfuscation:

I tried to run various de-obfuscators on my NR'ed program, ILDasm etc on the output without success.

In other words - it works for me Smile | :)

Cheers,

Glen Harvy

Re: LICENSING

mike montagne8-Mar-07 5:40

8-Mar-07 5:40

Similarly, I studied .NET licensing classes last night, and it's not really clear just how I'll want to go about writing a licensing scheme -- whether to use file I/O classes.

From what I see in the .Net SDK documentation, our license must be marked with a *.LIC extension.

The name of the file must be the fully qualified name, including the namespace, of the class with the file name extension .LIC. For example:<br />
<br />
Namespace1.Class1.LIC

This is not the case for the NR license (.license), so the NR system must be proprietary. That's OK with me -- it may be a much better thing to do, because I find the VS .Net SDK documentation quite ambiguous too. For instance,

The content of the license file should contain the following text string:<br />
<br />
"myClassName is a licensed component."<br />
<br />
myClassName is the fully qualified name of the class. For example:<br />
<br />
"Namespace1.Class1 is a licensed component."

Personally, I read this stuff and ask myself what it can mean to anyone. I want to know how this string, "Namespace1.Class1 is a licensed component." is processed. You would suppose that if it is removed or altered that this invalidates the license, but how and why -- and what alternate processes take over then? By the time you have deciphered all the cryptic documentation an unexplained issues (by costly experimentation), you can have far too much time in a small bit of functionality. A crux of the design issues is splitting the design time behavior and runtime behavior of distributables. The documentation seems to suggest this happens, but not how. You return a validation value by overriding a method.

Unfortunately, I don't see the path as being very clear here either. Like you, I most appreciate the fact that the NR licensing scheme will be hidden by a process beyond obsfucation -- and that is presently the deciding factor in the fork I'm going to take here, especially as I have now heard from Denis, and he's agreed to let me help him improve NR's documentation. My thinking is that I'll get my job done faster with more direct help, and that if we can improve the documentation, it may be very clear what to do with what my intuition tells me is the most promising way to distribute commercial .Net assemblies which require (or benefit from) intellectual property protection.

I'll read your other posts now, but will report back in the next few days if I can, on what progress Denis and I have made with his documentation. This should be interesting.

m

Re: LICENSING

Glen Harvy8-Mar-07 11:50