The notion of multiple processes has been around a long time, at least since the IBM 360. Multiple processes running at the same time, in separate memory spaces with protection from each other.
(In this context, I'm not talking about the distinction between one or several physical CPU cores, so 'at the same time' can equally well mean really physically at the same time, or with preemptive multitasking that makes it look like at the same time.)
Threads differ from processes in that they run in the same memory space, they have mutable shared memory, so if thread A pokes a value into a memory location, thread B reading that memory location a few microseconds later, expects to see the value A just put there.
Now, the Amiga had preemptive multitasking with no memory protection, so tasks on that machine could do the above, but it's not exactly what you were supposed to do. You were supposed to send a message from one task to the other, with a pointer to the block of memory that was being transferred. At the hardware level, nothing special was happening, but you were at least theoretically supposed to program according to that logic, with a view to later versions of the machine adding an MMU. (Which didn't actually happen, partly because by the time the 68030 with its built-in MMU came along, too much software had already been written that ignored the rules and would break, and partly because by that time, Commodore R&D was being mismanaged into the ground, but I digress.)
I'm not talking about that. Not talking about 'this machine doesn't have an MMU so you can get away with poking anything you want wherever you want'.
I'm talking about 'thread A pokes a value into their shared memory space, thread B expects to read that value a few microseconds later without explicitly passing a message or copying or even transferring ownership of a block of memory' as a supported API, something you are supposed to do.
(In a single-core system, the only difference is what the documentation says about what will be supported in the future. In a multicore system, mutable shared memory of this kind requires special hardware support for cache coherence. Different CPU architectures nominally have different models in terms of exactly how strongly they support various versions of this, but in practice, once you allow mutable shared memory, everything is under pressure to converge on the strongest model because otherwise you get Heisenbugs showing up on your platform and not on your competitors', which is the worst case scenario, e.g. Apple M1 has an optional TSO mode for x86 emulation; I predict in a few years it will just go TSO all the time and eat the efficiency cost.)
By that definition, when did the first system add explicit support for threads? I vaguely remember some time in the early nineties, Windows NT added it, the various UNIX vendors spent a while arguing they were a bad idea (a position I happen to agree with, but that's another matter) before being reluctantly forced to follow suit. (Why? As a marketing bullet point, or because cross-platform software like Oracle was being rewritten to assume threads? If the latter, why was it? If because it performed better that way, why did it?) But that's a vague memory, and doesn't preclude the possibility that – as very often turns out to be the case – mainframes had already done it a couple of decades earlier.