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

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"

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? ;^)

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

On 1/18/2024 2:17 PM, John Levine wrote:
> 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.
>
>
>

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

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?

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.

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.

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?

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.

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.

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.

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.

On 1/19/2024 11:28 AM, George Neuner wrote:
> 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.

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.

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.

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.

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?

On 1/19/2024 12:24 PM, Lawrence D'Oliveiro wrote:
> 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.

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...

>
> 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 <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.

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.