Disambiguation time

Multitasking when a computer works on several problems at once.

Prallelism is when several problems are being worked on in a single time slice. Concurrency is when one problem is worked on per time slice, but the problem being worked on changes from slice to slice.

True parallelism requires one hardware thread (or CPU core) per task. The kernel offers preemptive mulitasking as an alternative for when CPU time is over-committed (which is literally always, and badly); it "pre-empts" tasks and switches between them in each time slice, which is effectively a kind of transparent concurrency.

Cooperative multitasking is the opposite of preemptive multitasking, and in this case each task decides for itself when to relinquish control to another task. A common way of achieving this is coroutines.

A process is a task with its own isolated memory space. A thread is a task within a process, which shares its memory space. Multithreading is using multiple threads, multiprocessing is using multiple processes.

Did I miss anything?

@sir Processors can also do parallelism on single-threaded programs. They're allowed to process instructions out of order as long as the result is the same, which is why you often see compilers reorder statements that are related to add unrelated statements in between.

@ben I thought about talking about pipelining and speculative execution and so on but better to leave that for a CPU-design-specific post

@ben @sir I love how you found the neat way around the "single core per parallel operation" but arrived at ooo/speculative execution instead of vectorisation like in SSE and other SIMD extensions/architectures

@sir this is an insteresting take, IMHO multithreading is not fundamentally broken but is de-facto broken.

However I think the Rust language can really help unbreak multithreading as it enforce correct sharing of resources between the threads. Which is the de-facto broken part.

@sir @amdg2 Out of curiosity, what's your opinion on SMP/multi-core machines in general? Multithreading in the kernel is still multithreading.

@ecs @amdg2 multithreading without a shared address space is basically equivalent to multiprocessing

@ecs @amdg2 it's the shared address space which is a footgun

@sir @ecs so if sharing is safe because the language guarantee it, is multi-threading fine in your opinion ?

@sir @ecs looking forward to see what you baked in secret project :)

@sir @amdg2 @ecs I know this is poking the dragon a bit, but have you expressed the reasoning behind your rust distain anywhere? Not that you're obliged to obviously, but I'm genuinely curious.

@sir @amdg2 but the kernel will still use one address space across all the cores

@ecs @amdg2 aye, I don't like multithreaded kernels either. Microkernels are coolio yo

@sir @ecs @amdg2 a system with no threads but light weight processes and built in message passing could be cool.

@sir I don't think your definition of concurrency is right.

@sir upon re-read, I think it is correct enough for the context in which you've stated it

@sir MIMD architecture and vectorial execution. :ablobdevil:

@sir Failure modes? Debugging/diagnosing?
These two aspects are pretty critical for every system (not only software).

@_1751015 lol I wasn't trying to explain all of computer science in my post

thanks for the disambiguation, this actually helped me.

The last paragraph is unclear to me: what precisely is the difference between thread, process and task?

@maltimore a task is anything your computer is working on. A thread is a task which shares the same address space with other tasks; a process is a task with its own address space. More or less.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!