Is there a way to "fake" threading on a system that doesn't support it?

Is there a way to "fake" threading on a system that doesn't support it?

Attached: Bs3IYvyIAAAHu_p.jpg (480x640, 37.69K)

its called an operating system

Yes, you section off the memory to each thread (or user, etc) and then you timeshare the CPU between all those threads/users.

Attached: 1643837820419.jpg (1024x719, 150.04K)

context switching? or if your os doesn't support it, a loop that does it by itself.

fippy

What's fake about that? That's just an implementation of threading.

Spawn one process per thread and set all allocated memory that isn't per-thread as shared between the processes.

You can do it without the hardware actually supporting it or having protected memory, that's the closest to "faking" you're going to get.
Unless you write a single program with aplets that's actually a single thread and everything else runs on/in that.

Because there is no parallelism

It's actually timesharing, more like a early implementation of threading

>You can do it without the hardware actually supporting it or having protected memory
We've had OS threads for much longer than we've had hardware threads. No hardware support or protected memory is necessary for threading, they're just additional improvements.
Threads do not need to run in parallel. Do you think threads just don't exist on single-core CPUs?

>Threads do not need to run in parallel.
I understand. But a real operating system can use multiple cores to compute in parallel. So if that poster is asking about the difference between scheduling/time sharing and real life threads, that's it.

this is embarrassing

>if that poster is asking about the difference between scheduling/time sharing and real life threads
He's not. Can you read?

what is a "real life thread" to you???

multithreading at its simplest is a feature of an operating system to allow the ability to timeshare a core. Its software. Hardware can be designed to help support more efficient implementations. Implementing threading on multiple cores and with pipelining just means the problem has more edge cases to handle

What you want are called green threads. Basically, you have threads that are managed by a library and do time sharing on a singular OS thread. They won't run on multiple cores simultaneously.

How do green threads stop the execution of the running process? Is it cooperative or preemptive multitasking?
Would a while(1){} hang up the whole program?

cooperative

How does the compiler decide where in the program to hand off execution back to the scheduler?

i don't know, ask the compiler

Compilers have nothing to do with task scheduling.

The thread gets executed for a predetermined amount of time. After that time elapses, an interruption is generated. The interruption is handled and control is given to the scheduler. The scheduler "switches" to the next thread that should be executed, and then resumes the activity of the CPU.

Do you know what cooperative multitasking is? Unless you are manually calling the scheduler signaling that your thread is done, then the compiler must be inserting those hand-off function calls automatically according to some criteria.
>The thread gets executed for a predetermined amount of time.
Then it's preemptive multitasking, not cooperative.
>The interruption is handled and control is given to the scheduler. The scheduler "switches" to the next thread that should be executed, and then resumes the activity of the CPU.
You mean an interrupt? Those have to be handled by the kernel.
If you still require a context swap to the kernel to switch between green threads then I don't see what the advantage is compared to normal OS threads.