OK, I think I know... the problem is I might be wrong.
In general, if a variable is guaranteed to be written to by only one thread, it can be read by others with no problem. Correct?
More specifically, I could use a ConcurrentDictionary, but don't think it is necessary. The idea is that a Windows Form will start a thread with a polling operation. The thread will be to keep the form responsive.
I want the Form to display the number of jobs found in the polling operation.
I plan to create a dictionary<string,string> in the Form with a few entries, say:
"continue","true" and "jobs", "0"
If a Stop button on the Form is clicked, the value of "continue" in the dictionary will be set to "false". The while loop in the thread will read that and know to stop. Before that though, each time it polls, it will change the value of "jobs" in the dictionary to a string representing the number of polls (not really, but that is a real simple example). Now back in the Windows Form, a timer will be running and it will be reading that "jobs" value in the dictionary and displaying it.
The point is that only one thread will ever update the value of a KeyValuePair<string,> in the dictionary. The other thread will read it, but only one thread will ever write to that pair. Is that going to be safe to do? It doesn't even matter if the value is correct. It will be the next time the loop/event occurs.
Now I think the answer is that it is safe to do that, but if not, how about just sending a string, that is two strings. If only one thread is ever going to write to that string after the thread starts, does it matter what thread reads it or when?
I could even use an Interlocked.Increment(), but the question is whether a normal variable is safe to sue if only one thread ever writes to it.
All descriptions of threading seem to be about complicated situations. This is just simple.