Re: Threads (was Re: MSI interrupts)

Scott Lurndal wrote:

Robert Finch <robfi680@gmail.com> writes:

On 2025-03-30 11:33 p.m., Dan Cross wrote:

 

I think this stems from this idea you seem have that threads
somehow turn into "processors/cores", whatever that means, as
these are obviously not the hardware devices, when interrupts
are disabled on the CPUs they are running on.  Near as I can
tell this is your own unique invention, and nothing else uses
that terminology; use by the systems you cited is not supported
by evidence.
>
Consequently, I find your repeated assertions about these terms
rather strange.
>
- Dan C.
>

Having some trouble following the discussion as I do not have a lot of
experience working with software threads. I know they need
synchronization means.
>
Are you talking about two different kinds of “threads”? RISCV at least
refers to ‘harts’ which I think stands for hardware threads. A CPU core
may support multiple harts, which implies multiple copies of the
processor state. In a multi-core system there could be multiple harts
even though each core is only supporting a single one. I am under the
impression hardware and software threads are not the same thing.
I hope I got the lingo correct.

 In the abstract, a thread can be considered a sequence of instructions
executed with a consistent processor state (registers, flags, MMU).
 Threads, using that definition, can be implemented fully in software
(using OS facilities for coordination between entities).   User-mode
threads are an example of this, and were implemented in systems that
did not have Operating system support for threads as a schedulable
entity.
 Operating systems later added explicit support for multiple threads
of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register
state, et alia).  POSIX Pthreads was the standard on the Unix side.
 Subsequently, the hardware vendors realized that they could better
utilize the hardware by creating the concept of a 'hardware thread'
where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading).
 

In my programmer world view, a pure user software thread isn't that interesting, it typically allows the programmer to control (more or less) when it can be interrupted.
A harware thread is anything which could, at any time (even in the middle of a long-running instruction like a block move), interrupt the currently executing thread and potentially modify anything in the local context which isn't currently locked down.
I.e. just like a separate processes running on another core, except that (nearly) nothing is really private. This makes for a much more "interesting" programing environment.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"