Hello!

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

What is the exact difference here?

--
kind regards
Marco

Spam und Werbung bitte an ichwillgesperrtwerden@nirvana.admins.ws

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marco Moock wrote:

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


--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>:

On 1/18/2024 12:14 AM, Marco Moock wrote:

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.



--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 09:14:05 +0100, Marco Moock wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

As opposed to syntax, perhaps?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 1/18/2024 2:17 PM, John Levine wrote:

According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 23:55:01 -0500, George Neuner wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 10:29:17 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Marco Moock wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Jan 2024 06:19:12 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

On Thu, 18 Jan 2024 23:55:01 -0500, George Neuner wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jan 2024 21:23:33 -0800, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 1/18/2024 8:55 PM, George Neuner wrote:

On Thu, 18 Jan 2024 14:28:03 -0800, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:

On 1/18/2024 2:17 PM, John Levine wrote:

According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Jan 2024 13:02:26 -0600, BGB wrote:

Though, on most systems:
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 19 Jan 2024 13:02:26 -0600, BGB wrote:

Though, on most systems:
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Jan 2024 20:49:06 GMT, Scott Lurndal wrote:

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 19 Jan 2024 20:49:06 GMT, Scott Lurndal wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marco Moock wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)