1) Is "green threads" something supported in all JVMs ?
If not, then what is the reason that it is not supported by some of them ?
2) Do all modern general purpose operating systems support native threads ?
In general, modern VMs do not use green threads. These days Thread Pooling is more common.
The question is too broad. What do you mean by all operating systems? Embeded systems on a variety of chips included? Most general purpose OS running on modern processors do have native threads.
Related
I am studying Solaris and Linux and am viewing Kernel Level Threads (KLTs) as the fundamental entity that can be scheduled and dispatched by the OS. I know that a multi-threaded OS must store thread execution context and provide mechanisms to schedule and dispatch KLTs, and that kernel level threads handle interrupts, system calls, and provide an interface to the CPU as a resource at the user-kernel interface. I am not clear on what services are necessary to support KLTs in a multi-threaded OS.
I cannot determine if there is a core kernel process that is necessary to support all KLTs, or if KLTs run interdependently as the base-level of computing. I would like to understand what minimum set of operations (resource allocation, scheduling) is necessary to support an OS with KLTs.
I have looked at Tanenbaums Tanenbaum's discussion of threads in his distributed systems book, Understanding the Linux Kernel, and MultiThreading the SunOS kernel but I cannot find an answer to my question.
I believe that answering the question -- What Operating System services are necessary to support kernel-level threads? -- will help me understand how KLTs are implemented.
I am using some QThread based worker threads in KDE Neon 18.04 (based on Ubuntu 18.04, Kernel 4.15.0-46-generic). The worker threads interfered with my desktop applications so I decided to reduce their priority.
The Qt documentation of QThread::start(priority) says:
The effect of the priority parameter is dependent on the operating
system's scheduling policy. In particular, the priority will be
ignored on systems that do not support thread priorities (such as on
Linux, see http://linux.die.net/man/2/sched_setscheduler for more
details).
After reading the above documentation I expected priorities would have no effect on my Linux system. Still I gave it a try. And guess what - it worked perfectly.
So, why does the Qt documentation state there would be no thread priorities on Linux? And why does it work anyway?
Depending on which flavour of Linux/Unix/*Nix you use the scheduler may or may not support it. As far as I'm aware the majority of Qt's priority levels are supported on most Linux systems now, but not all of the priority levels. I suspect the documentation says it's unsupported so they don't need to list every combination of OS variant and scheduler variant that do support priority levels and which levels are supported.
You can validate it has created it with the correct priority by using htop or top and processing with awk: https://unix.stackexchange.com/questions/19301/what-is-a-command-to-find-priority-of-process-in-linux
Why did the first Linux developers choose to implement a non-preemptive kernel? Is it to save synchronization?
As far as I know, Linux was developed in the early 90's, when PCs had a single processor. What advantage does a non-preemptive kernel give in such PCs? Why, however, the advantage is reduced by multi-core processors?
Remember that Linux was intended to be somewhat compatible with the versions of Unix already out there, notably System V and BSD.
Unix of that era was very primitive compared to the commercial operating systems available at that time and in many ways remains so to this day. The big selling point of Unix in the 1990 was "open systems." Unix allowed the various upstart computer companies (e.g., Apollo, Sun) to have an operating system without doing much operating system development. They were able to turn the really poor quality of Unix compared to commercial operating systems of the day (e.g. VMS) into an advantage as an "open system."
One of the many features lacking in Unix was a preemptive kernel. If you are building a Unix clone, there was little reason to create one.
There are DEC and IBM systems that run for years without rebooting. It's amazing how far backwards we have gone.
If, for example, there is a let's say embedded application which run on unicore CPU. And then that application would be ported on multi core CPU. Would that app run on single or multiple cores?
To be more specific I am interested in ARM CPU (but not only) and toolchain specifics e. g. standard C/C++ libraries.
The intention of this question is this: is it CPU's responsibility to "decide" to execute on multiple cores or compiler toolchain, developer and standard platfor specific libraries? And again, I am interested also in other systems' tendencies out there.
There are plenty of applications and RTOS (for example Linux) that run on different CPUs but the same architecture, so does that mean that they are compiled differently?
Generally speaking single-threaded code will always run on one core. To take advantage of multiple cores you need to have either multiple processes, multiple threads, or both.
There's nothing your compiler can do to help you here. This is an architectural consideration.
If you have multiple threads, for example, most multi-core systems will run them on whatever cores are available if the operating system you're running is properly compiled to support that. Running an OS that's been compiled single-core only will obviously limit your options here.
A single threaded program will run in one thread. It is theoretically possible for the thread to be scheduled to move to a different core, but the scheduler cannot turn a single thread into multiple threads and give you any parallel processing.
EDIT
I misunderstood your question. If there are multiple threads in the application, and that application is binary compatible with the new multicore CPU, the threads will indeed be scheduled to run on different CPUs, if the OS scheduler deems it appropriate.
Well it all depends on the software that if it wants to utilize other cores or not (if present). Lets take an example of Linux on ARM's cortexA53.
Initially a vendor provided boot loader runs on, FSBL (First state bootloader). It then passes control to Arm trusted firmware. ATF then runs uboot. All these run on a single core. Then uboot loads linux kernel and passes control to it. Linux then initializes some stuff and looks into some option, first in the bootargs for smp or nosmp flags. if smp it will get the number of CPUs assigned to it from dtb and then using SMC calls to ATF it will start other cores and then assign work to those cores to provide true feel of multiprocessing environment. This is normally called load balancing and in linux it is mostly done in fair.c file.
I'm asking this question because I was investigating the Haiku OS (a BeOS descendant).
The goal of the BeOS operating system was to create a desktop environment that handles multimedia well and is very responsive. They manage this by creating a kernel that has "pervasive multi threading".
Other operating systems (Linux, Windows etc.) don't have this "pervasive multi threading" and hence, aren't that responsive. (no flame wars please...)
Could someone explain the (subtle) differences between the "pervasive multi threading" (like in BeOS/Haiku) and the multi-threading used in Windows or Linux?
What are the implications for a developer for the different multi threading systems?
I found an interesting site about BeOS Multi-threading...
BeOS Multi threading
Copied from an answer I made for the now closed question "What is/was so terrific about BeOS [closed]", but applies here quite nicely:
From memory, the odd thing about BeOS development is that the GUI really is multithreaded, unlike GUI frameworks on other platforms, which tend to be absolutely single-threaded.
This meant that developing GUI applications for BeOS is completely different, but I assume that this meant the GUI's were more responsive, without requiring explicit design at the application level for handling GUI interactions.
Of course, this does mean that using mutexes and the like are more important, and porting GUI applications from other OS's to BeOS are difficult unless the BeOS GUI library is effectively turned into a single-threaded library by using and enforcing a single application-wide mutex.
Linux, Windows, and almost all other OS's I can think off that I've used in the past decade support multithreading, Linux and windows both which utilise multithreading in substantially different ways but do so very well - however, BeOS really uses multithreading pervasively - and this is made obvious by, eg, the GUI framework, whereas most others are strictly single-threaded. (Or, at the most extreme, permit multiple threads from access with undefined consequences...)