Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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 Aug 31 '12 at 12:27
add comment

2 Answers 2

up vote 11 down vote accepted

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?
share|improve this answer
    
Could you explain your second point a little bit? –  Qix Aug 31 '12 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 Aug 31 '12 at 12:49
    
Ohh okay, CPU caches weren't popping into mind. Make sense! –  Qix Aug 31 '12 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 Aug 31 '12 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 Sep 1 '12 at 10:52
show 1 more comment

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.

share|improve this answer
    
If I could accept 2 answers, I would. –  Qix Aug 31 '12 at 14:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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