There seems to be other thread safety issues in the implementation of globals:

• Creating globals is racy:

  jruby/core/src/main/java/org/jruby/internal/runtime/GlobalVariables.java

  Lines 173 to 180 in 01f9f01

  	private GlobalVariable createIfNotDefined(String name) {
  	GlobalVariable variable = globalVariables.get(name);
  	if (variable == null) {
  	variable = GlobalVariable.newUndefined(runtime, name);
  	globalVariables.put(name, variable);
  	}
  	return variable;
  	}

• UndefinedAccessor just replaces the GlobalVariable's accessor field, which is not volatile, which could lead to reading a nil (if the invalidator is not checked such as on the slow path) when the variable was already set.

Nice find, thanks. I feel like the way our globals are structured needs a reboot (the current way is WAY over-abstracted) but I'll have a look at fixing this in place for now.

A fix is in for 9.1.14 that basically just disables the caching like @eregon did. I am resolving this as fixed and will file a separate bug for the many race conditions we need to deal with.

I've updated the code in #5536 to gracefully fall back on a volatile field when a global is modified more than MAXFAIL times. That PR appears to allow this script to run safely with any number of threads all contending the globals (resolving #4808).