When you run this program and hit Enter to suspend, the program hangs.
But if you change the worker function to just "for(;;) {}" the program
runs fine.
Let's see if we can figure out why.

The worker thread spends nearly all its time calling System.Console.WriteLine,
so when you call Thread.Suspend(), the worker thread is almost certainly
inside the System.Console.WriteLine code.

Q: Is the System.Console.WriteLine method threadsafe?

Okay, I'll answer this one: Yes. I didn't even have to look at any
documentation to figure this out. This program calls it from two
different threads without any synchronization, so it had better be
threadsafe or we would be in a lot of trouble already even before
we get around to suspending the thread.

Q: How does one typically make an object threadsafe?

Q: What is the result of suspending a thread in the middle of a threadsafe
operation?

Q: What happens if - subsequently -
you try to access that same object (in this case,
the console) from another thread?

These results are not specific to C#. The same logic applies
to Win32 or any other threading model.
In Win32, the process heap
is a threadsafe object, and since it's hard to do very much in
Win32 at all without accessing the heap, suspending a thread
in Win32 has a very high chance of deadlocking your process.

So why is there even a SuspendThread function in the first place?

Debuggers use it to freeze all the threads in a process while you
are debugging it. Debuggers can also use it to freeze all but one
thread in a process, so you can focus on just one thread at a time.
This doesn't create deadlocks in the debugger since the debugger
is a separate process.