Re: Threads (was Re: MSI interrupts)

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Scott Lurndal wrote:

 

In the abstract, a thread can be considered a sequence of instructions
executed with a consistent processor state (registers, flags, MMU).
=20
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.
=20
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.
=20
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).
=20

>
In my programmer world view, a pure user software thread isn't that=20
interesting, it typically allows the programmer to control (more or=20
less) when it can be interrupted.

 Using the pre-pthreads posix facilities (signals and getcontext/setcontext)
to support user-level threads wasn't uncommon.  Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level
threads in an M-N setup (M user threads multiplexed on N kernel threads).
 Didn't turn out to be particularly useful.