About thread safety where only one thread writes...

Question

0.00/5 (No votes)

See more:

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.

Thanks, Mike

Posted 31-Jul-15 5:27am

Michael Breeden

Updated 31-Jul-15 5:34am

v4

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-07-31T05:51:00

Solution 1

If one thread reads from a dictionary, and another writes to dictionary, this dictionary is required to be thread-safe. But you can use a collection which is not thread-safe, because you can sandwich both operations (or all other operations accessed from different threads of the same collection object) in a lock statement using the same lock object. It's better not to use an accessible object (such as collection, or any object hosting it) as a lock object, to prevent using it directly. To protect from such cases, this object should be private, not accessible by the calling code.

Theoretically speaking, this is not a strictly required rule, just one simple and reliable pattern. You can always invent more relaxed synchronization rule which sometime could improve some average throughput. For example, you can design a schema that grants access to a collection element in a mutually exclusive manner, but you can have the operations on an element object which are done in parallel when two elements are different. It is especially easy to do if the elements are reference-type objects.

The whole idea to use a dictionary by different thread might be considered questionable. More typically, blocking collections are used. For example, I cannot see how it helps to keep the application responsive; the usual approach is to Control's or Dispatcher's Invoke or BeginInvoke, accessing no data in the UI, using only the data passed through UI thread invocation. Also remember: best synchronization is no synchronization. Maybe you improve your application threading design.

Don't get me wrong: I'm not saying you should not do it; for more certain advice, more detailed understanding of what you are trying to achieve would be required.

—SA

Posted 31-Jul-15 5:51am

Sergey Alexandrovich Kryukov

Updated 31-Jul-15 6:01am

v3

Comments

Michael Breeden 31-Jul-15 12:13pm

The last point is the easiest to answer. This is being developed in a Windows Forms application, but the classes are structured so that it could run in a console or Windows Service. The classes that do the work, do not "talk back" to their parents at all, though the parent (form, console, service) can get or set values in the thread.

As I mentioned, I can use a the thread safe ConcurrentDictionary or even a couple of Interlocked.Increment operators and be thread safe instead of using locking, but I am really more curious about if there would be a problem using:
1. A normal dictionary if only one thread will ever write to a a keyValuePair in it, though another thread will be doing the read.
2. A normal property (string) if only one thread will ever write to it, though another thread will be reading it.

Thanks, Mike

Sergey Alexandrovich Kryukov 31-Jul-15 14:40pm

All right. I did not get what "point" are you answering to in your first paragraph, but such applications are quite possible. I used to develop whole technology where the same exact application, without any modifications, can serve as a Windows Service or as an interactive application, depending on how you start it. Still, it's not clear how you design it and deal with threading, but the whole thing is quite doable.

1) You really cannot access the same collection without locking (ConcurrentDictionary simply uses locking or other mutual exclusion facility internally, and Interlocked, generally, does not really solve the problem).
2) In many cases, you can improve throughput in cases when only one thread is writing data, and other threads are only reading. In such cases, you can use the class System.Threading.ReaderWriterLockSlim. I illustrated its use in my article Wish You Were Here… Only Once.

Will you accept my answer formally now? In all cases, your follow-up questions will be welcome.

—SA

Michael Breeden 31-Jul-15 15:23pm

I'm sorry, but I must be explaining my intent very badly and you seem to be solving the trivial problem I present with a sledge hammer. I think this question is a bit too simple minded for you.
How about this? Please use the numbers and tell me if they are correct or incorrect. You do seem to have a deep enough knowledge of this to know these fine points.
1. As far as I know, there is no inherent reason that a normal variable cannot be read/write by two threads as long as it is in the scope of both (parent and child thread...).
2. If two threads try to write to the same variable at the same time, there can be a problem of creating an indeterminate (random) value in the variable. There will be no exception though.
3. If two threads try to read from the same variable at the same time, there should be no problem and the correct value will be read.
4. Even if two threads try to write to the same variable, but at different times, there should be no problem, no exception and the value of the variable will be correct after the individual writes.
5. If one thread writes to a variable and another reads the variable, even at the same time, it will not lead to an exception or an indeterminate value. It will be the value of the variable either before or after the write.

Really, I'm trying to build a wagon, not a race car. It is not about data, it is about flags controlling application behavior. I'm just trying to find out some details about what some thread behavior would be without using locking. All I have to work with are very old memories from basic classes.

Sergey Alexandrovich Kryukov 31-Jul-15 17:39pm

1) Strictly speaking, it's not exactly so. That's why you have Interlocked.
2) Right. I guess, you did not mean random, you mean few different values depending on the order of execution. In other words, this is a potential race condition.
3) Strictly speaking, it's not exactly so. But yes, exceptions are irrelevant to this.
4) So, but this is exactly why either Interlocked or mutual exclusion is used, otherwise what can guarantee that "different time"?
5) Right.
Now, the problem is: your mistake was to reduce everything to reading and writing a single variable. We probably have some understanding here. But this is wrong to jump with the same considerations to the access to a collection. Accessing a member of a collection is never a single step. You first get access to a member, obtain its address, them you get the reference (for a reference type), dereference it, and then work with the object.
—SA

Michael Breeden 31-Jul-15 18:24pm

#2. Fascinating. Didn't know was race condition, but the memory is very old.
I'm going to mark as answered and I do thank you for your time and expertise. I think I got the understanding I was looking for. Do you recommend an article on Interlocked for #1? Thanks again, Mike

Sergey Alexandrovich Kryukov 31-Jul-15 20:02pm

Great.
By the way, I consider the term race condition as a very unfortunate term which confused many who assumed it was something else, but this short name. I first faced with this concept under the name "incorrect dependency on the order of execution". A bit too long, but less confusing.
—SA