That sounds like a process, processes are scheduled by the operating system. Threads are not, they are scheduled by an application.

No, activities (threads) were totally scheduled by the operating system. This was not cooperative multitasking. All those activities are in the same address space.

Here's Dijkstra's P and V, implemented for EXEC 8 by John Walker, who later wrote AutoCAD. These are user space primitives built on top of the OS primitives ACT$ and DACT$. This is part of an application called FANG, an overdesigned utility for doing various copies with as much parallelism as possible.

I once modified a Pascal compiler for that system to support multi-threading. I could get about a hundred activities going.

The main difference from threads today is that there's no concept of a stack. There can be a heap allocator, and you can save state, but the whole concept of a stack is absent.

No, you are not using the standard definition of a thread [1]. What you are calling a thread would normally be called a userspace thread, green thread, fiber, stackful coroutine, etc. Note the specific qualifiers distinguishing them from the overarching concept of a thread which can be broadly classified as a scheduled instruction stream.

edit: Just to be clear, "thread" is itself also just one of many names for the general concept. Task, Activity, Actor, etc. may be used, but they might also refer to something completely different. It is really a question of checking that the properties of the named thing match the properties of the standard definition of a "thread".

[1] https://en.wikipedia.org/wiki/Thread_(computing)

Processes aren’t scheduled by the OS, threads are. But many processes only consist of one thread, so there’s only one thing to schedule. Processes are commonly a collection of threads with a single shared address space among them.