views:

164

answers:

4

I am writing a program where there is an object shared by multiple threads: a. multiple write threads write to the object (all running the same function) b. a read thread which accesses the object every 5 seconds c. a read thread which accesses the object there is a user request

It is obviously necessary to lock the object when writing to it, as we do not want multiple threads to write to the object at the same time.

My questions are:

  1. Is it also necessary to lock the object when reading from it?
  2. Am I correct to think that if we just lock the object when writing, a critical section is enough; but if we lock the object when reading or writing, a mutex is necessary?

I am asking this question because in Microsoft Office, it is not possible for two instances of Word to access a document in read/write access mode; but while the document is being opened in read/write mode, it is possible to open another instance of Word to access the document in read only mode. Would the same logic apply in threading?

Thank you.

+2  A: 

It is necessary, because otherwise (unless operations are atomic) you may be reading an intermediate state.

You may want to allow multiple readers at the same time which requires a (bit) more complex kind of lock.

Ofir
The write operation is atomic, but thank you very much for your answer.
Andy
+2  A: 

Is it also necessary to lock the object when reading from it?

If something else could write to it at the same time - yes. If only another read could occur - no. In your circumstances, I would say - yes.

Am I correct to think that if we just lock the object when writing, a critical section is enough; but if we lock the object when reading or writing, a mutex is necessary?

No, you can use a critical section for both, other things being equal. Mutexes have added features over sections (named mutexes can be used from multiple processes, for example), but I don't think you need such features here.

anon
Thank you. I now realise that critical sections can be used for different subroutines, as long as the subroutines belong to the same process.
Andy
+1  A: 
  1. depends on how you use and read it. if your read is atomic (i.e, won't be interrupted by write) and the read thread does not have dependency with the write threads, then you maybe able to skip read lock. But if your 'read' operation takes some time and takes heavy object interation, then you should lock it for read.

  2. if your reading does not take a very long time (i.e., won't delay the write threads too long), critical section should be enough.

Francis
+3  A: 

As Ofir already wrote - if you try to read data from an object that some other thread is modyfying - you could get data in some inconsistent state.

But - if you are sure the object is not being modified, you can of course read it from multiple threads. In general, the question you are asking is more or less the Readers-writers problem - see http://en.wikipedia.org/wiki/Readers-writers_problem

Lastly - a critical section is an abstract term and can be implemented using a mutex or a monitor. The syntax sugar for a critical section in java or C# (synchronized, lock) use a monitor under the covers.

Michał Bendowski
Thank you very much for all your answers.
Andy