I know that there is multithreading vs multiprocessing approach.
But I was under the impression that threads are implemented as processes by the OS. So the threading model is just a programming construct on top of processes.
At least in Java (hence the tag although this question is language agnostic) I know that the threads are implemented by the linux as processes
Is it not the general case? Does it depend on the OS?
UPDATE for Java asked in comment by #SotiriosDelimanolis: One to one mapping of Java Thread to Linux thread (LWP)
Threads in modern versions of Java are "native" and are implemented, scheduled and handled by the OS the JVM is running on. So the answer depends on which OS you are using.
Distinguishing between Java threads and OS threads?
EDIT
In general, not just java, the rules for how threads are created is determined by the language, the OS and and language libraries that are used (or some combination of those).
But in general, on modern OSes, multiple threads often share a single process for performance reasons. Threads are sometimes called light weight processes.
This link has an overview of threads and C libraries for writing multithreaded apps for various OSes.
Related
My CS professor told to the class that the OS has no idea that an application has launched threads. Is this true?
It depends on the type of thread. Threads implemented purely at user-level would be unknown to the operating system. This can be done with signals and setjmp and longjmp (see www.gnu.org/s/pth/rse-pmt.ps for details). Alternatively, if you are talking about something such as Linux pthreads, which only implements of subset of the pthreads specification, specifically the part that involves create new threads of execution that the kernel are aware of and schedules then the kernel is aware.
If you want to see more detail about how the kernel is aware you can look at the the clone system call. This system call can be used to create a new thread of execution that shares the address space of the calling process.
Also in the case of user-space implemented threading you will not get true parallelism, in the sense that two threads will be executing at the exact same time on different cores/hardware threads, because the operating system, which does the scheduling, does not know about the multiple threads.
It depends upon the operating system. Older operating system had no threads. Programming libraries would implement threads (e.g., Ada tasks) with timers. The library included a thread scheduler.
It is increasingly common now for operating systems to schedule threads for execution. There, the OS is aware of threads.
After reading many threads related material, I'm still confused about the ULT and KLT.
How kernel treats two ULT of same process? Can two user level threads of same process run simultaneously on multi core CPU? If yes, is it done by kernel or library function?
Since the Linux version 2.6, the standard implementation is NPTL
(Native Posix Thread Library) which assign 1 User level thread to 1 kernel thread (actually Linux "knows" only tasks -not processes neither threads- circa 8kb of kernel memory).
Just in case of a multi-processor/core machine (CONFIG_SMP defined in the kernel code) one thread may be allocated on any available processor. In Linux any processor has a "run-queue" (which in case of SCHED_NORMAL or SCHED_OTHER a red-black tree data structure is used to contain a list of task ready to run. "Migration" of task between two run-queue is possible.
I hope this help to clarify!
_ _
Kasper.
Can two user level threads of same process run simultaneously on multi core CPU?
Yes, one of the main reasons to use threads is to increase performance by working concurrently on independent computations.
If yes, is it done by kernel or library function?
The kernel is responsible for managing the resources provided by the hardware, including the multiple cores in a multi core CPU. The kernel provides a programming interface (system calls) to be used by user space libraries, which in turn provide an interface (abstraction layer) to user applications. There are many libraries and programming language extensions for managing threads, here's a good overview
https://software.intel.com/en-us/articles/choosing-the-right-threading-framework
In short, the kernel ultimately is where threads are created, scheduled to run, context switched, wait for events, and destroyed. Multi-threaded user programs use library functions and/or language extensions to manage threads, these provide different abstraction levels above the kernel.
can any one please tell me. Are all term "kernel thread", "native thread" and "Os thread" represent kernel thread? Or they are different? If they are different what is relationship among all?
There's no real standard for that. Terminology varies depending on context. However I'll try to explain the different kind of threads that I know of (and add fibers just for completeness as I've seen people call them threads).
-- Threading within the kernel
These are most likely what your kernel thread term refers to. They only exist at the kernel level. They allow (a somewhat limited) parallel execution of the kernel code itself.
-- Application threading
These are what the term thread generally means. They are separate threads of parallel execution which may be scheduled on different processors, that share the same address space and are handled as a single process by the operating system.
The POSIX standard defines the properties threads should have in POSIX compliant systems (in fact the libraries and how each library entry is supposed to behave). Windows threading model is extremely similar to the POSIX one and, AFAIK, it's safe to talk of threading in general the way I did: parallel execution that happens within the same process and can be scheduled on different processors.
-- Ancient linux threading
In the early days the linux kernel did not support threading. However it did support creating two different processes that shared the same address space. There was a project (LinuxThreads) that tried to use this to implement some sort of threading abilities.
The problem was, of course, that the kernel would still treat them as separate processes. The result was therefore not POSIX compliant. For example the treatment of signals was problematic (as signals are a process level concept). It was IN THIS VERY SPECIFIC CONTEXT that the term "native" started to become common. It refers to "native" as in "kernel level" support for threading.
With help from the kernel actual support for POSIX compliant threading was finally implemented. Today that's the only kind of threading that really deserves the name. The old way is, in fact, not real threading at all. It's a sharing of the address space by multiple processes, and as such should be referred to. But there was a time when that was referred to as threading (as it was the only thing you could do with Linux).
-- User level and Green threading
This is another context where "native" is often used to contrast to another threading model. Green threads and userl level threads are threads that do happen within the same process, but they are totally handled at userlevel. Green threads are used in virtual machines (especially those that implement pcode execution, as is the case for the java virtual machine), and they are also implemented at library level by many languages (examples: Haskell, Racket, Smalltalk).
These threads do not need to rely on any threading facilities by the kernel (but often do rely on asynchronous I/O). As such they generally cannot schedule on separate processors. In these contexts "native thread" or "OS thread" could be used to refer to the actual kernel scheduled threads in contrast to the green/user level threads.
Note that "cannot be scheduled on separate processors" is only true if they are used alone. In an hybrid system that has both user level/green threads and native/os threads, it may be possible to create exactly one native/os thread for each processor (and on some systems to set the affinity mask so that each only runs on a specific processor) and then effectively assign the userlevel threads to these.
-- Fibers and cooperative multitasking
I have seen some people call these threads. It's improper, the correct name is fibers. They are also a model of parallel execution, but contrary to threads (and processes) they are cooperative. Which means that whenever a fiber is running, the other fibers will not run until the running fiber voluntarily "yields" execution accepting to be suspended and eventually resumed later.
I've read about Preemptive Multithreading here and here.
Is there a way to do this in Delphi and how does this compare (advantages and disadvantages) to other methods of threading in Delphi?
The "other methods" you're referring to all seem to be using the operating system's underlying threading capability -- which is preemptive. In other words, choose whichever you find most convenient, and it'll be preemptive.
Getting non-preemptive (aka cooperative) threading requires a bit of extra work, typically by converting threads to "fibers".
Modern versions of Windows are all preemptive multitasking operating systems. This means that threads and processes (where a process to exist requires at least one thread of execution) are all scheduled and preemptively run.
So "is there a way to do this in Delphi" has the following answers:
Your singlethreaded Delphi application is already preemptively scheduled with the other applications
If you write a multithreaded Delphi application, it also will be. You would have to go to considerable effort to write a non-preemptive model, such as a cooperative threading model in your application. One approach might be to use coroutines; here is an example using Delphi 7.
The best answer is use TThread or any native Windows thread or wrapper around them. You will have preemptive multithreading.
All the models in your link use normal Windows threads and I suspect your question means you're confused about different threading techniques, which are mostly techniques for communication or running tasks (jobs of work that are run on other threads.) If this is the case, you might want to either update your question or ask another looking for an explanation of these models.
Have you looked at User-Mode Scheduling which was introduced in Windows 7. Fibers basically don't really work. There's lots of information on this on the MSDN site and I seem to recall a few videos on Channel 9.
Is there an advantage of the operating system understanding the characteristics of how a thread may be used? For example, what if there were a way in Java when creating a new thread to indicate that it would be used for intensive CPU calculations vs will block for I/O. Wouldn't thread scheduling improve if this were a capability?
I'm not sure what you're actually expecting the OS to do with the information that a thread is I/O or compute. The things which actually make the most difference to how threads get scheduled (ie thread priority and thread CPU affinity) are already exposed by APIs (and support for NUMA aspects are starting to appear in mainstream OS APIs too).
If by a "compute thread" you mean it's something doing background processing and less important than a GUI thread (from the point of view of maintaining app responsiveness) probably the most useful thing you can do is lower the priority of the compute threads a little.
That's what OS processes do. The OS has sophisticated scheduling for the processes. The OS tracks I/O use and CPU use and dynamically adjusts priorities so that CPU-intensive processing doesn't interfere with I/O.
If you want those features, use a proper OS process.
Is that even necessary? Threads blocking on I/O will cause CPU-intensive threads to run. The operating system decides how to schedule threads. AFAIK there's no way to give any hints with Java.
Yes, it is very important to understand them specially if you are one of those architects who like opening lot of threads, specially on windows.
Jeff Richter over at Wintellect has a library called PowerThreading. It is very useful if you are developing applications on .NET, but since you are talking about JAVA, it is still better to understand OS threads, kernel models and how the interrupts work.