-4

Sample coding below:

private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
  string var1 = "sample 1";
  //display in UI var1
  string var1 = "sample 1.1";
  //display in UI var1
}

private void backgroundWorker2_DoWork(object sender, DoWorkEventArgs e)
{
  string var1 = "sample 2";
  //display in UI var1
  string var1 = "sample 2.1";
  //display in UI var1
}

private void backgroundWorker3_DoWork(object sender, DoWorkEventArgs e)
{
  string var1 = "sample 3";
  //display in UI var1
  string var1 = "sample 3.1";
  //display in UI var1
}

Will it cause the threads to slow down because they are using the same variable? Or will it cause the wrong values to be shown at the UI since the value is always changing? My program will have a lot of threads so I worry about the potential unforeseen consequences.

Crescendo26
  • 171
  • 6
  • In what sense are they using the same variable? And what value is changing? – David Schwartz Nov 13 '17 at 02:23
  • 2
    It is not clear what you're asking. Each thread you show has a local string variable that is not used anywhere else right now. – mnistic Nov 13 '17 at 02:24
  • sorry my mistake. I have edited the coding – Crescendo26 Nov 13 '17 at 02:28
  • 2
    I'm afraid it's still not clear, because in the code you show there is obviously nothing to slow the threads down, and as long as you use invoke to update the controls from the main thread, you should be OK. – mnistic Nov 13 '17 at 02:37
  • @mnistic I'm new to multithreading so I'm not sure whether threads have to take turns accessing a variable with the same name thus slowing down the overall UI. I was just wondering whether different threads refer to the same reference variable or not. Answer by Theraot has cleared up my misunderstanding. – Crescendo26 Nov 13 '17 at 06:49

1 Answers1

1

These are local variables, they exist independently of each other and the compiler and the runtime will never mix them up because they are... local to where they were declared. In fact, local variables are not a concern for threading, see Thread safety and local variables [*].

Once compiled, the name of local variables is lost (they will be - the equivalent of saying - local variable 1, local variable 2, etc...). That is, in Microsoft Intermediate Language, the name of local variables is irrelevant. See OpCodes.Ldloc Field.

Will it cause the threads to slow down because they are using the same variable?

No. These are unfounded worries. These local variables have nothing to do with each other.

Or will it cause the wrong values to be shown at the UI since the value is always changing?

This could happen regardless of variables names. What matters is what value you show in UI, and when and where you show it. What was the name of the variable holding it has no impact.

My program will have a lot of threads so I worry about the potential unforeseen consequences.

Worry not about local variables. Once we start talking about some form of shared memory across threads then you have a reason to worry. And no, local variables are not shared across threads, let me be clear here: they are local [**].

I want to suggest Joseph Albahari's series Threading in C#. Which despite being outdated [***] are well written, have clear examples, and get all the fundamentals across.

With that said, naming variables is important for readability and maintainability of the code. Anyway, I am not in the mood to preach. So, you do you. I will only say on the matter this: the next time you see a variable and you are not sure what it is or where else you might be using it, think about it.

[*]: The answer to the linked question mentions two ways a local variable could be exposed. Both amount to upgrade the local variable to a field of ana nonymous object behind the scenes (yield return copies the value to a hidden IEnumerator, on the other hand if make a closure on a local variable and share it, you are sharing the local variable - in a hidden anonymous class).

[**]: Even if you are using async/await and the method was resumed in a different thread, there is no chance two threads will share the local variable (it changed hands, but you usually have no reason to worry about that, unless you are using ThreadLocal or similar).

[***]: these days we will be using async/await, in fact, why are you using BackgroundWorker?

Theraot
  • 31,890
  • 5
  • 57
  • 86
  • Well, I have gotten advice from here to try and use BackgroundWorker for an easier and more convenient method of handling multithreading..is there any problem with backgroundWorker? – Crescendo26 Nov 13 '17 at 03:24
  • thanks. I think your answer has cleared up the my doubts – Crescendo26 Nov 13 '17 at 03:24
  • @user107257 `BackgroundWorker` works. The niche use case is in UI, which is its intended use. On [The answer to WinForm Application UI Hangs during Long-Running Operation](https://stackoverflow.com/a/1216799/402022), it is old, `async/await` didn't exist at the time. `async/await` is the recommendation going forward, although that does not mean you have get rid of `BackgroundWorker` (you may even mix'em). See also [Async in 4.5: Enabling Progress and Cancellation in Async APIs](https://blogs.msdn.microsoft.com/dotnet/2012/06/06/async-in-4-5-enabling-progress-and-cancellation-in-async-apis/). – Theraot Nov 13 '17 at 04:39
  • thank you so much for your advice. I will keep in mind about async/await for my future projects. – Crescendo26 Nov 13 '17 at 06:45