0

I have a Data Transfer Object (DTO) in a Java application that is being read from and written to in several different threads across the application. Up until now I have been able to use synchronized(dto.class) for synchronization. There is now one instance where I need to hold the lock outside of the method that it is called in, so I will use the ReentrantLock() class.

Is there a thread safe way to use a reentrant lock for its functionality in the one instance while keeping the synchronized blocks as is in the rest of the code? Or, is it the case that the use of a reentrant lock means all related synchronized blocks have to be removed?

jlaufer
  • 89
  • 8
  • `synchronized` blocks are also reentrant. If you're locking on `dto.class` you could also this from a method that is not in that class. – Alex R Oct 10 '22 at 19:23
  • @AlexR, One thing you can do with `ReentrantLock` that you cannot do with `synchronized` is, you can lock it in one scope (e.g., in one method), and you can unlock it in a different scope (e.g., in a different method). In my _personal_ opinion, that's not a smart thing to do, but that's what the OP wants to do. – Solomon Slow Oct 10 '22 at 21:51
  • I would reconsider the approach. I would definitely not allow for concurrent access to a DTO object because it beats the purpose of the object; it is a simple data exchange object and should not have functions beyond that. – pveentjer Oct 12 '22 at 02:14
  • @pveenjer I ended up just changing out all synchronization blocks for ReentrantLocks. Works fine and as far as I know it is the simplest way to share data between physical objects (say a motor controller and a camera). Any other relevant programming language has middle ware for doing such things (like ROS for C++/Python) but unfortunately Java has nothing useful so I'm stuck with synchronizing DTOs. If there is actually a proven and stable solution out there that doesn't require DTOs, I'd love to know about it. – jlaufer Oct 12 '22 at 03:40

1 Answers1

0

Is there a thread safe way to use a reentrant lock for its functionality in the one instance while keeping the synchronized blocks as is in the rest of the code?

What data do the synchronized blocks protect? What data do you want to protect with the ReentrantLock? If they're different data then there should be no problem using different means to protect them. But it doesn't make any sense to use synchronized in one place and ReentrantLock in a different place if you're trying to protect the same data in both places. Locking a ReentrantLock will not prevent some other thread from entering a synchronized block and vice versa.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57
  • It's the same data. The only way I can image using both on the same data would work would be by having the ability to extract the implicit lock from the synchronized class. Why it "makes any sense" is because although the reentrant lock gives the flexibility needed for real-time applications, it also makes the code even more difficult to follow (or "tightly coupled" or whatever they say). – jlaufer Oct 11 '22 at 02:22