GILs are at a lower level than that. A GIL is used to protect the internal state of the interpreter.

You (or your standard library) need ruby-level locks in ruby code when you do things like increment a counter. E.g.: "obj.count = obj.count + 1".

The interpreter needs interpreter-level locks when doing things like looking up attributes from an object's dictionary or hash table or whatever ruby calls it. That's why you don't always need a lock around a simple assignment to avoid interpreter crashes: "obj.count = 0" is safe. Without a ruby-level lock around that, there is a race condition with the previous example, and resetting the count to zero may not have an effect if you're unlucky.

Without a GIL, however, you could have problems like the interpreter segfaulting (instead of throwing a nice execption that you can handle). You may also have problems like that assignment turning into an infinite loop, depending on ruby's implementation of hash tables.

And if accessing a hash table isn't safe, you can't even use ruby-level locks. How would you create a lock? You'd need to access classes or functions in a module. The module stores those things in a hash table, which you can't access without a lock. That's what the GIL is for.