Thread-safety isn’t just about word tearing. It’s also about state invariants in your program. Even if all your threads are green threads on the same OS thread, you still have to guard critical sections that check-and-modify, or that temporarily break the invariants of state that is observable by other threads, when there’s anything in-between that may lead to a context switch. Otherwise, while you may be free of word tearing, you might still have “torn” program state.

On a single-core CPU, word tearing may similarly be absent between OS threads, but you still have to guard any critical section.

I agree with user swiftcoder that there are concurrency issues (like the above) even in the absence of hardware parallelism, or of multiple OS threads (which by themselves don’t imply hardware parallelism). I disagree that “thread-safety” isn’t an appropriate term for them. Those issues are part of what thread-safety was always about.

I think my contention is that a lot of programmers don't think about thread-safety in those terms - if I write a purely single-threaded program, thread-safety seems like the kind of thing that I don't have to care about (when in reality, the fact that various OS-provided features like signals exist, mean that all software has to deal with concurrency issues)