OPERATING SYSTEM

1. Linux OS
 Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads
as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent
threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique
task_struct and appears to the kernel as a normal process (which just happens to share resources, such as an address space,
with other processes). This approach to threads contrasts greatly with operating systems such as Microsoft Windows or Sun
Solaris, which have explicit kernel support for threads (and sometimes call threads lightweight processes). The name "lightweight
process" sums up the difference in philosophies between Linux and other systems. To these other operating systems, threads are
an abstraction to provide a lighter, quicker execution unit than the heavy process. To Linux, threads are simply a manner of
sharing resources between processes (which are already quite lightweight)11. For example, assume you have a process that
consists of four threads. On systems with explicit thread support, there might exist one process descriptor that in turn points to
the four different threads. The process descriptor describes the shared resources, such as an address space or open files. The
threads then describe the resources they alone possess. Conversely, in Linux, there are simply four processes and thus four
normal task_struct structures. The four processes are set up to share certain resources.

Android OS

 Every Android developer, at one point or another, needs to deal with threads in their application. When an application is
launched in Android, it creates the first thread of execution, known as the “main” thread. The main thread is responsible for
dispatching events to the appropriate user interface widgets as well as communicating with components from the Android UI
toolkit. To keep your application responsive, it is essential to avoid using the main thread to perform any operation that may end
up keeping it blocked. Network operations and database calls, as well as loading of certain components, are common examples
of operations that one should avoid in the main thread. When they are called in the main thread, they are called synchronously,
which means that the UI will remain completely unresponsive until the operation completes. For this reason, they are usually
performed in separate threads, which thereby avoids blocking the UI while they are being performed (i.e., they are performed
asynchronously from the UI). Android provides many ways of creating and managing threads, and many third-party libraries
exist that make thread management a lot more pleasant. However, with so many different approaches at hand, choosing the
right one can be quite confusing. In this article, you will learn about some common scenarios in Android development where
threading becomes essential and some simple solutions that can be applied to those scenarios and more.
Linux OS


 A process in LINUX is a single program running in its own virtual space on the operating system. To create a process in LINUX, the
‘parent process‘ initiate a fork(). Fork() suggests that the process creates a copy of itself. A process in LINUX is represented by a
data structure (like PCB) is called ‘task-struct‘. It contains the all information about the process. The LINUX Task Structure are as
followed: 1. PID: It is a unique process identification number. 2. State: It specifies one of the 5 states of a process. 3. Scheduling
 OPERATING SYSTEM

Information: It specifies that which type of information needed. 4. Links: Process having the link to its parent process if it is a
child process. If it is a parent process links to all of its children. 5. File System: It includes pointers to any files opened by this
process. 6. Virtual Memory: It defines the virtual memory assigned to this process. 7. Times and Timers: It specifies process
creation time, CPU burst time of a process, etc. 8. Processor-specific context: The registers and stack information that constitute
the context of this process. It includes Ready and Executing states. 2. Interruptible: It is a suspended state when the process or
thread is waiting for an event, then it enters into an interruptible state. 3. Uninterruptible: It is another suspended state, here the
process or thread is waiting directly on Hardware conditions. 4. Stopped: The process or thread has been halted and it can only
resume by a positive action from another process or thread. 5. Zombie: It terminates when the execution completes.
 Linux in LPAR mode can use the simultaneous multithreading technology on mainframes. IBM® z13® introduced the
simultaneous multithreading technology to the mainframe. In Linux terminology, simultaneous multithreading is also known as
SMT or Hyper-Threading. With multithreading enabled, a single core on the hardware is mapped to multiple logical CPUs on
Linux. Thus, multiple threads can issue instructions to a core simultaneously during each cycle. To find out whether
multithreading is enabled for a particular Linux instance, compare the number of cores with the number of threads that are
available in the LPAR. You can use the hyptop command to obtain this information. Simultaneous multithreading is designed to
enhance performance. Whether this goal is achieved strongly depends on the available resources, the workload, and the
applications that run on a particular Linux instance. Depending on these conditions, it might be advantageous to not make full
use of multithreading or to disable it completely. Use the hyptop command to obtain utilization data for threads while Linux runs
with multithreading enabled. You can use the smt= and nosmt kernel parameters to control multithreading. By default, Linux in
LPAR mode uses multithreading if it is provided by the hardware.
 Yes, it can be increased but Linux has a limit on the number of threads. The threads-max kernel parameter can be set to ensure
that the number of threads per process is always less than or equal to that limit. However, other factors like the amount of
virtual memory and stack size may indirectly govern the number of threads allocated to a process. The Linux kernel handles both
a process and a thread in the same way. So, values limiting the number of processes will indirectly also limit the number of
threads. Although there are system parameters that set a limit on the number of threads per process, the OS and memory likely
become the limiting factors well before that. Thus, the number of threads per process can be increased by increasing total virtual
memory. The amount of stack size per thread is more likely to be the limit than anything else. Reducing the per-thread stack size
is also a way to increase the total number of threads.
 First of all, Linux doesn't create multiple virtual CPUs for a single CPU hardware. That means your kernel module must be
designed for hardware architecture. Also keep in mind that prior to 2.6 kernel there was no threading support in Linux kernel.
That means most likely any software written prior to 2.6 will not have threading support. As present we are at Linux kernel
version 4.x and 5.x. But if you have old software which you want to repurpose keep these things in mind. Second: all of your cores
will show up as different CPUs. That means if you have hardware with 16 cores or 64 cores, then Linux can make the computer
work like a 64-node mini super computer. That means if you have written some software in a distributed computing paradigm,
you can port it on Linux with minimal rewriting of code. If your distributed system was designed to utilize different independent
processes which work on each of node, don't despair: Linux has a facility called "setting up affinity". You can set a process'
affinity with a CPU. This is available in both application mode and kernel mode. Using this facility, you can bind different
processes on a given core to furnish it with a dedicated CPU. To the best of my knowledge, in User space even after setting an
affinity, other processes will run on the core when needed. In kernel space things are more restrictive. Third, I have seen many
seasoned professionals falling apart at this point so please pay special attention to this when designing your software systems. I
am not exaggerating. Many VP level people forget this minor detail and open doors for software nightmares. "Linux kernel treat
kthreads same as an independent process." This one line seems like a simple and understandable statement but its implications
are huge. I will give two examples where you will fail horribly under stress.
 https://www.linkedin.com/pulse/multi-threading-linux-mihir-sevak
https://www.baeldung.com/linux/max-threads-per-process
https://www.ibm.com/docs/en/linux-on-systems?topic=mc-simultaneous-multithreading-4
https://webeduclick.com/solaris-threads-in-operating-system/
 OPERATING SYSTEM

Android OS


The reason behind this whole discussion was because of the fact that threads are an inevitable part of android development.

 In every project we have a main and this main is our application thread. Whenever an application is launched main thread is
created. This thread is responsible for dispatching all the application components, including widgets and views. The main thread
is also known as UI thread.
Separate threads are not created for each instance of component. Components belonging to the same process are instantiated
by this main thread. Procedures which prick call back methods are run on this thread. For example, when you touch checkbox,
Application or app’s UI thread dispatches touch event to the widget. When we are performing long running tasks, the thread
must be very well managed otherwise it would take too long for processing. If thread is blocked then it may result in ANR or
Application Not Responding error i.e., our app hangs. Background thread must never block UI thread as all manipulations are to
be done from UI. There are two rules while programming : UI thread should not be blocked Android UI toolkit should only be
accessed by UI thread. No other thread should try to access it.
 Android can use multiple CPU cores for multithreading, but the kernel and JVM handle that process, not the developer himself.
An internal multithreading design will improve the program's basic performance, but the device upon which it actually runs will
determine its speed. Developers multithread Android applications in order to improve their performance and usability. By
spinning off processor- or resource-intensive tasks into their own threads, the rest of the program can continue to operate while
these processor intensive tasks finish working. This can include separating the thread for the graphical user interface from the
threads that fetch network data. The JVM automatically manages these multiple tasks, so Android developers do not have to
concern themselves with optimizing thread performance for a particular set of hardware.
 Yes. Technically there is no limit, but at some point, having more threads is going to be less efficient than having less. If you want
to see a pretty much optimal implementation of a ThreadPool. Maximum number of threads possible to run on an Android device
depends on whether the device has a 32-bit processor or a 64-bit processor and stack size of Android. But you will have memory
constraints way before you reach the actual maximum limit.
 Making adept use of threads on Android can help you boost your app’s performance. This page discusses several aspects of
working with threads: working with the UI, or main, thread; the relationship between app lifecycle and thread priority; and,
methods that the platform provides to help manage thread complexity. In each of these areas, this page describes potential
pitfalls and strategies for avoiding them. When the user launches your app, Android creates a new Linux process along with an
execution thread. This main thread, also known as the UI thread, is responsible for everything that happens onscreen.
Understanding how it works can help you design your app to use the main thread for the best possible performance.
 https://developer.android.com/topic/performance/threads
https://stackoverflow.com/questions/35136345/maximum-number-of-thread-android
https://smallbusiness.chron.com/android-multithreading-performance-37880.html
https://developer.android.com/guide/components/processes-and-threads
https://www.wideskills.com/android/application-components/android-threads-and-processes
https://www.toptal.com/android/android-threading-all-you-need-to-know