This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

synchronize on writes but not on reads.  RSS feed

 
wayne forrest
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi,

Is it safe/legal to synchronize only for write operations, but not on reads, assuming data
is stored in an array ( or non thread safe collection )?

Also asume there are many getter threads and many setter threads, and that the data stored will be Objects and not primitives.

I am particular concerned about corrupt data, where thread 1 writes and halfway through the process thread 2 reads the data.
(If data is re-read(stale data) it is ok.)




 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No - all access to an object must be synchronized. What is called
a "dirty read" can occur if a read operation is allowed while a write
operation is in progress.

Jim ... ...
 
Paul Clapham
Sheriff
Posts: 22503
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wayne forrest wrote:Also assume... that the data stored will be Objects and not primitives.


If this makes a difference, then the answer to the question must be "It depends". It depends on the semantics of the objects in question. If they are immutable, then probably they act like primitives in that you won't see partial changes to their state.

Or perhaps you were concerned about references to objects changing in blocks which potentially should be synchronized? Again this leads me to believe that there's more to this question than just Yes or No.
 
Madhan Sundararajan Devaki
Ranch Hand
Posts: 312
Java MS IE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please use an appropriate class from the java.util.concurrent package.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... such as java.util.concurrent.locks.ReadWriteLock.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have to ask the question the answer is you need both, ask yourself the question why is there a WriteLock and a ReadLock.

Even if you use 32bit primitives to avoid word tearing you still have problem of correctly publishing your value. Immutable is a lovely idea but you have to fully understand the difference between thread immutable and just what the average programmer calls immutable.

The problem is if you read without a lock your code may just read a previously cached value for a number of reasons (Java optimisation, CPU caching).

I previously had to fix an open source library where some one decided that they only needed a sync on a setter and not the getter which was followed up by a bug report where the getter failed to see the result of a previous set on another thread.

I strongly urge you not to attempt to code like this, it is possible to do i.e. correct use of final, static, volatile, new JAVA Fence API etc etc but unless this is a critical optimisation is almost certainly a waste of time and incredibly easy to get wrong.
 
assert assertion
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I will say it depends on a case to case basis. If all your threads are doing is updating values in a map, they don't care (Read) what other threads are doing with that object, we would only sync setter. But in case when you have a race condition, lilke the famous producer consumer problem you have to synchronize access to object and you will have to lock read and write access.
 
Pankaj Kumarkk
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My answer would be that read operations also should be accessed in synchronized manner. The reason for that is below:
Synchronization gives you 2 guarantees: 1) Locking : No thread can access the same code with same lock. 2) Visibility: The changes are visible to all threads at the same time.

It is for "visibility" part that you want to make the reads also synchronized.

Having said the above, I would suggest that you should use appropriate class from concurrency package as the concurrency classes typically allow reads without the big overread of synchronization.
Hope it helps.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!