3

Theoretically, thread-safe code should fix race conditions. Race conditions, as I understand it, occur because two threads attempt to write to the same location at the same time.

However, what about a threading model in which a single thread is designed to write to a location, and several slave/worker threads simply read from the location?

Assuming the value/timing at which they read the data isn't relevant/doesn't hinder the worker thread's outcome, wouldn't this be considered 'thread safe', or am I missing something in my logic?

Improve this question
1
  • 1
    One writer alone does not guarantee safety, as long as operation like check then read is not guaranteed to be atomic. 1) thread1: reader1 checks if not empty - OK 2) thread2: reader2 checks if not empty - OK 3) thread1: reader1 reads - OK 4) thread2: reader2 reads - oops reader1 already emptied queue at step #3
    – gnat
    Commented Aug 31, 2012 at 12:27

2 Answers 2

Reset to default
12

There are two problems:

  • If there is more than a single value being written, then without synchronization the reading threads could see partially written and thus inconsistent data. Even single values could be read in a partially written state that corresponds to none of the legitimate values (e.g. in Java, writing to double and long fields is not guaranteed to be atomic).
  • Reading threads could get outdated values for an arbitrarily long time after it's been written, due to caching. If that's not a problem, why have a writing thread at all?
Improve this answer
6
  • Could you explain your second point a little bit?
    – Qix - MONICA WAS MISTREATED
    Commented Aug 31, 2012 at 12:38
  • 4
    @Di-0xide: CPU cores often have separate caches. So if a thread running on core 1 updates data in RAM, all threads that run on cores 2,3,4 will keep seeing the old value in their cores' cache, potentially for a long time. Synchronization forces the caches to be updated (which is what makes it so expensive).
    – Michael Borgwardt
    Commented Aug 31, 2012 at 12:49
  • Ohh okay, CPU caches weren't popping into mind. Make sense!
    – Qix - MONICA WAS MISTREATED
    Commented Aug 31, 2012 at 13:02
  • As I understand the matter, cache coherence protocols ensures that a new value is eventually seen, so arbitrary long time before seeing a write is possible only on systems without such protocol, they are rare. Note that cache coherence systems bring their own set of problems -- false sharing for instance.
    – AProgrammer
    Commented Aug 31, 2012 at 19:47
  • @AProgrammer: as I understand it, cache coherence protocols don't actually have eventual visibility of all changes as a goal, only that all processes see the same sequence of changes in each separate memory location.
    – Michael Borgwardt
    Commented Sep 1, 2012 at 10:52
4

There are more problems than that.

  • write may not be atomic, that is a thread could see a partially updated value

  • even if all writes are atomic, you may get in the situation where you write A then B but another thread see the new B and the old A. You need some synchronizations instructions to ensure that you see everything that you want. Those instructions may be needed in both threads, not just the writer or the reader one.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.