thread vs process

[Marco Moock]

Hello!

Some programs say that they are multi-process or multi-threaded.

What is the exact difference here?

[Terje Mathisen]

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

Welcome to comp.arch where we really love this kind of homework questions!

The difference is of course mostly one of semantics only, where
multi-threaded means that each cpu follows a single thread of execution,
working independently, whereas multi-process has a bunch of cpus all
cooperating on a single task.

Terje

[Lawrence D'Oliveiro]

The difference is of course mostly one of semantics only ...

As opposed to syntax, perhaps?

[Michael S]

On Thu, 18 Jan 2024 10:29:17 +0100

Post by Terje Mathisen

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

Welcome to comp.arch where we really love this kind of homework questions!
The difference is of course mostly one of semantics only, where
multi-threaded means that each cpu follows a single thread of
execution, working independently, whereas multi-process has a bunch
of cpus all cooperating on a single task.
Terje

I am not sure about it.
IMHO, first and foremost it is a matter of what industry you are in.
The programs used in textile tend to be multi-threaded.
On the other hand, food industry is known to rely on multi-process
programming, sometimes detrimentally to their consumer's health.

[Chris M. Thomasson]

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

What about multiple multi-threaded processes? ;^)

[John Levine]

Post by Chris M. Thomasson

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the previous excellent answer.

[Chris M. Thomasson]

Post by John Levine

Post by Chris M. Thomasson

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the previous excellent answer.

Multiple multi-threaded processes are impossible? Really? Since when...

[George Neuner]

On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by John Levine

Post by Chris M. Thomasson
What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the
previous excellent answer.

Multiple multi-threaded processes are impossible? Really? Since when...

I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

[Chris M. Thomasson]

Post by George Neuner
On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by John Levine

Post by Chris M. Thomasson
What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the
previous excellent answer.

Multiple multi-threaded processes are impossible? Really? Since when...

I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

I wonder if I missed his main point?

[George Neuner]

On Thu, 18 Jan 2024 21:23:33 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by George Neuner
On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by John Levine

Post by Chris M. Thomasson
What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the
previous excellent answer.

Multiple multi-threaded processes are impossible? Really? Since when...

I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

I wonder if I missed his main point?

If so I missed it too. John seemed to refer to Terje's answer which
is about what (virtual) CPUs are doing in either case.

Terje's answer is correct but incomplete: it appears to imply that
multiple threads cannot be doing the same task, and that multiple
processes must be doing the same task. Neither necessarily is true.

[BGB]

Post by George Neuner
On Thu, 18 Jan 2024 21:23:33 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by George Neuner
On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson"

Post by Chris M. Thomasson

Post by John Levine

Post by Chris M. Thomasson
What about multiple multi-threaded processes? ;^)

You know perfectly well that's architecturally impossible. See the
previous excellent answer.

Multiple multi-threaded processes are impossible? Really? Since when...

I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

I wonder if I missed his main point?

If so I missed it too. John seemed to refer to Terje's answer which
is about what (virtual) CPUs are doing in either case.
Terje's answer is correct but incomplete: it appears to imply that
multiple threads cannot be doing the same task, and that multiple
processes must be doing the same task. Neither necessarily is true.

Though, another way to see it would be that:
Threads and processes can do whatever, and there need not be a hard
distinction.

Though, on most systems:
Threads run in the same address space;
Processes run in different address spaces, and typically represent
different programs.


Fun on a system where everything runs in one address space and the
distinction between threads and processes is a bit more ambiguous.

[Lawrence D'Oliveiro]

Post by BGB
Threads run in the same address space;
Processes run in different address spaces, and typically represent
different programs.

The usual way of saying it is threads are “shared-everything” and
processes are (nearly) “shared-nothing”, at least by default.

On a POSIX system, you create one of the former with pthread_create(3),
and one of the latter with fork(2). But on Linux, both of these are
basically wrappers around clone(2)
<https://manpages.debian.org/2/clone.2.html>. And by using that call
directly, you get some interesting options for creating entities that are
somewhat in-between.

[Scott Lurndal]

Post by BGB
Threads run in the same address space;
Processes run in different address spaces, and typically represent
different programs.

The usual way of saying it is threads are “shared-everything” and
processes are (nearly) “shared-nothing”, at least by default.
On a POSIX system, you create one of the former with pthread_create(3),
and one of the latter with fork(2). But on Linux, both of these are
basically wrappers around clone(2)
<https://manpages.debian.org/2/clone.2.html>. And by using that call
directly, you get some interesting options for creating entities that are
somewhat in-between.

SVR4.2ES/MP had two versions of fork.

fork(2) would only create a single thread in the forked process
forkall(2) would create a new process with all the same threads as the
parent process.

The latter never gained any traction and when POSIX.4 came along, wasn't
accepted by the standard working group.

[Lawrence D'Oliveiro]

Post by Scott Lurndal
SVR4.2ES/MP had two versions of fork.
fork(2) would only create a single thread in the forked process
forkall(2) would create a new process with all the same threads as the
parent process.
The latter never gained any traction and when POSIX.4 came along, wasn't
accepted by the standard working group.

Big surprise ...

Did they try to explain what the point of it was?

[Scott Lurndal]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
SVR4.2ES/MP had two versions of fork.
fork(2) would only create a single thread in the forked process
forkall(2) would create a new process with all the same threads as the
parent process.
The latter never gained any traction and when POSIX.4 came along, wasn't
accepted by the standard working group.

Big surprise ...
Did they try to explain what the point of it was?

I don't recall the details. There wasn't much experience
with unix threads at the time ('90ish), other than the
digital ultrix threads. It's probably in one of the ES/MP
design documents I have squirrelled aways somewhere.

[Chris M. Thomasson]

Post by Lawrence D'Oliveiro

Post by BGB
Threads run in the same address space;
Processes run in different address spaces, and typically represent
different programs.

The usual way of saying it is threads are “shared-everything” and
processes are (nearly) “shared-nothing”, at least by default.

Intraprocess communication is dealing with multiple threads of a single
process.

Interprocess communication is dealing with multiple processes.

A program can be comprised of multiple processes that have multiple
threads within them...

Interprocess communication can be interesting, for instance think along
the lines of robust mutexes.

Lock-free and wait-free sync algorithms can be used for both,
Intraprocess and/or Interprocess sync...

Post by Lawrence D'Oliveiro
On a POSIX system, you create one of the former with pthread_create(3),
and one of the latter with fork(2). But on Linux, both of these are
basically wrappers around clone(2)
<https://manpages.debian.org/2/clone.2.html>. And by using that call
directly, you get some interesting options for creating entities that are
somewhat in-between.

[Lawrence D'Oliveiro]

Post by George Neuner
I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

Those “hardware threads” are probably best described as “virtual CPUs”.
They have nothing to do with threads versus processes in the software
sense. They are a way of sharing functional units to make it look almost,
but not quite, like separate CPUs.

[George Neuner]

On Fri, 19 Jan 2024 06:19:12 -0000 (UTC), Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

Post by George Neuner
I think John may be assuming that a CPU/core runs only one thread at a
time ... which isn't necessarily true.

Those “hardware threads” are probably best described as “virtual CPUs”.
They have nothing to do with threads versus processes in the software
sense. They are a way of sharing functional units to make it look almost,
but not quite, like separate CPUs.

That's quite true. The point I was making was that multiple threads
of the same process can be running simultaneously even on the same
core.

[Lawrence D'Oliveiro]

Post by Marco Moock
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

Think of a bare-minimum context of execution: a program counter that
points at an instruction stream, and some machine state for executing
those instructions.

Obviously that’s not enough to run any meaningful program: you also need
memory to hold that instruction stream and associated data, plus other OS
context like open files, network connections, access-control credentials
etc. Call that “process context”.

So if two execution contexts have their own process contexts, you call
them “separate processes”. If they share the same process context, you
call them “threads within a process”.

I think that’s about as basic a definition as you can get.

[MitchAlsup1]

Post by Marco Moock
Hello!
Some programs say that they are multi-process or multi-threaded.
What is the exact difference here?

To actually try an answer your question::

Multi-process is a system that allows for multiple independent processes to share
one or more CPUs.

Multi-threaded is a system that allows for multiple processes and allows some of
them to share memory while occupying one or more CPUs in a system.

In some theoretical senses: multi-threaded is multiple threads within a single
address space (PThreads,...); although I soften that hard edge and allow even
processes which share memory through mmap() to be considered multi-threaded.