oshi: [version 3.13.0] SystemInfo (and many classes available via it) is not thread-safe

Instances of SystemInfo initialize its fields lazily, but without any synchronization, which leads to executions with data races and the possibilities of having either NullPointerException or observing default values for primitive fields.

After taking a first look, I thought “maybe users are not supposed to use SystemInfo concurrently”, but then I saw the question Are oshi SystemInfo instances thread safe?, and an answer

I’ve made reasonable efforts to try to avoid issues with thread safety, and many classes will work without a problem, I certainly can’t guarantee it

and realized that SystemInfo is actually supposed to be used concurrently… I am going to present a only a few issues, but I would expect that there are more problems.

Problem 1: lazy initialization without synchronization Consider SystemInfo.getHardware().getMemory().getTotal():

• a plain field SystemInfo.hardware is initialized lazily to a new instance of let’s say LinuxHardwareAbstractionLayer when SystemInfo.getHardware is called.
• a plain field LinuxHardwareAbstractionLayer.memory is initialized lazily to a new instance of let’s say LinuxGlobalMemory when LinuxHardwareAbstractionLayer.getMemory is called.
• a plain field LinuxGlobalMemory.memTotal is initialized lazily to a long value when LinuxGlobalMemory.getTotal is called.

All those fields are initialized without any memory synchronization. As a result writes to SystemInfo.hardware field produced by SystemInfo.getHardware method and reads from SystemInfo.hardware field produced by the same SystemInfo.getHardware method are not ordered with happens-before (HB) relation when SystemInfo.getHardware is called concurrently (unless a user of SystemInfo takes care of that…), and this means that executions contain data races. The mentioned reads of SystemInfo.hardware is allowed by the Java memory model to observe both writes to this field produced by SystemInfo.getHardware and the implicit write of the default value (this write exists in all executions regardless of whether the original code has it explicitly or not). The same is true for other mentioned fields, and thus there is no guarantee that we will not observe null in SystemInfo.hardware/LinuxHardwareAbstractionLayer.memory and 0 in LinuxGlobalMemory.memTotal.

Another slight sub-issue here is that concurrent executions of let’s say SystemInfo.getHardware may create multiple instances of LinuxHardwareAbstractionLayer. But this is because of a race condition that we have in the algorithm “check if hardware is initialized and initialize it if it’s not” (and a race condition is a different thing from a data race). But creating a few excessive objects is probably fine for this specific scenario (I don’t immediately see problems).

Problem 2: LinuxGlobalMemory.updateMeminfo and lastUpdate does not pave proper synchronization A plain field LinuxGlobalMemory.lastUpdate is being read and written in LinuxGlobalMemory.updateMeminfo method without any synchronization. It leads to the things described in Problem 1, specifically there is no guarantee that reads from lastUpdate in if (now - this.lastUpdate > 100) ever see anything other than 0, which would lead each invocation of LinuxGlobalMemory.lastUpdate to read from /proc/meminfo.

A race condition similar to the one mentioned in Problem 1 is also applicable here: LinuxGlobalMemory.lastUpdate may read from /proc/meminfo multiple times when called concurrently because now - this.lastUpdate > 100 appears to be true for multiple threads. Depending on the cost of reading from /proc/meminfo, it may or may not be a problem.