Could maybe be an issue for some really tight unit tests. In actual use the updates to those fields will be globally visible near instantly without volatile keyword.
> On 22 Feb 2023, at 13:17, Benjamin Lerer <b.le...@gmail.com> wrote: > > I have seen issues with some updatable parameters which were missing the > volatile keyword. > > Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko <alek...@apple.com > <mailto:alek...@apple.com>> a écrit : >> FWIW most of those volatile fields, if not in fact all of them, should NOT >> be volatile at all. Someone started the trend and most folks have been >> copycatting or doing the same for consistency with the rest of the codebase. >> >> Please definitely don’t rely on that. >> >>> On 21 Feb 2023, at 21:06, Maxim Muzafarov <mmu...@apache.org >>> <mailto:mmu...@apache.org>> wrote: >>> >>> 1. Rely on the volatile keyword in front of fields in the Config class; >>> >>> I would say this is the most confusing option for me because it >>> doesn't give us all the guarantees we need, and also: >>> - We have no explicit control over what exactly we expose to a user. >>> When we modify the JMX API, we're implementing a new method for the >>> MBean, which in turn makes this action an explicit exposure; >>> - The volatile keyword is not the only way to achieve thread safety, >>> and looks strange for the public API design point; >>> - A good example is the setEnableDropCompactStorage method, which >>> changes the volatile field, but is only visible for testing purposes; >>
