0

I have a large object that will be accessed by multiple threads continuously. But this object has to be updated periodically and while updating no thread shouldn't be blocked.

I think we can have a Timer to update the object that updates in a duplicate object and once the update is done we can update the object reference with the duplicate object.

Does any one has a better ideas to implement this effectively?

Anton Dozortsev
  • 4,782
  • 5
  • 34
  • 69
Chittibabu
  • 1
  • 1
  • But what if two threads create a duplicate object with updates at the same time? Then you will lose one of the updates. – Keppil Feb 10 '14 at 13:37
  • 1
    "while updating no thread shouldn't be blocked" that confuses me, since you need a thread to update it and the others need to wait while it is updated. – diazazar Feb 10 '14 at 13:37
  • Would you share some code to illustrate your problem? That would make it easier to share code to illustrate an answer. – Bex Feb 10 '14 at 14:03
  • Only one thread will update the object as configured by the timer and for the rest of the time it will be idle. – Chittibabu Feb 11 '14 at 05:51
  • What I meant by "while updating no thread shouldn't be blocked" was during the data pull and inserting the data into the object, other threads no need to wait until it finishes. They can run with the older data. – Chittibabu Feb 11 '14 at 05:53

1 Answers1

1

you can implement read/write locks for each property of the object unless you have dependencies between properties.

light_303
  • 2,101
  • 2
  • 18
  • 35
  • You should mention the ReentrantLock class. – Kayaman Feb 10 '14 at 13:50
  • There is only one property(object). The problem with read/write locks is every time you read you have to check whether the lock is free or not. And moreover, I don't want threads that reads this data will be blocked during the write. – Chittibabu Feb 11 '14 at 05:57
  • Maybe you can use a "copy on write" style update. That way the old object would be left in a consistent state and would then be replaced by a new object in one go. – light_303 Feb 14 '14 at 13:26
  • Can you elaborate it how can we do? I am just looking for different possible solutions for the problem. One way is we can make the object as volatile. If you have any other ways, I am happy to listen them. – Chittibabu Mar 06 '14 at 10:17
  • See ReadWriteLock in java.util.concurrent.locks. You would basically allow concurrent read access as long as there are no write operations in progress (locking before setting the property - unlocking afterwards). if this is done per property of a large object, you would gain a ConcurrentHashMap like striping effect – light_303 Mar 06 '14 at 12:13
  • Thanks but we don't want to have the locking overhead. – Chittibabu May 17 '14 at 18:19
  • The read locks basically cost you close to nothing. If you update a copy and only write lock during the swapping the update and the old entry, you should be very close to zero blocking – light_303 May 17 '14 at 20:32
  • Updates are very minimal so don't think locking would be needed here as it has extra overhead(may be minimum). Other than, locking can we any other way something like maintaining a duplicate copy and update the reference with the new object once the update is done. – Chittibabu Jul 19 '14 at 05:40
  • Ok.understood you are also telling the same thing. – Chittibabu Jul 19 '14 at 05:42
  • In general locking would only be required if your update are non-atomic. If not you would have a good chance of reading a half-updated state which could lead to interesting data corruption scenarios. – light_303 Jul 20 '14 at 22:22