equivalent function may not be threadsafe
goneall opened this issue · comments
ModelObject.equivalent does do any locks before retrieving the list of properties and comparing properties.
We could wrap it in a critical section, but if an equivalent is called on the other object (e.g. reverse the order of ModelObject parameters), it will cause a deadlock.
We may be able to just use synchronized methods.
Note that with the advent of Project Loom (available as a preview in JDKs 19+, and slated for release in JDK 21, the next LTS version), the synchronized keyword is no longer recommended, since it ties up a "carrier thread" (a physical OS thread) when synchronization happens.
The recommendation now is to use one of the java.util.concurrent.Lock implementations instead - they are "Loom compatible".
Good point @pmonks. We could create a high (course) level lock for all equivalent functions. This would ensure the lock hierarchy.
I did a more careful review of the code and came to the conclusion it is thread safe.
There is a window between collecting all the property names and comparing the actual properties. However, if the property goes away during that window, it will just show up as empty in Optional which will fail the compare. Since the object is changing during the equivalent call, I would think having it return false would be expected.