DOCSLIB.ORG

Introduction to Multithreading, Superthreading and Hyperthreading

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Introduction to Multithreading, Superthreading and Hyperthreading by Jon "Hannibal" Stokes Back in the dual-Celeron days, when symmetric program at the same time. This might sound odd, so multiprocessing (SMP) first became cheap enough in order to understand how it works this article will to come within reach of the average PC user, many first look at how the current crop of CPUs handles hardware enthusiasts eager to get in on the SMP multitasking. Then, we'll discuss a technique called craze were asking what exactly (besides winning superthreading before finally moving on to explain them the admiration and envy of their peers) a dual- hyper-threading in the last section. So if you're processing rig could do for them. It was in this looking to understand more about multithreading, context that the PC crowd started seriously talking symmetric multiprocessing systems, and hyper- about the advantages of multithreading. Years later threading then this article is for you. when Apple brought dual-processing to its PowerMac line, SMP was officially mainstream, As always, if you've read some of my previous tech and with it multithreading became a concern for the articles you'll be well equipped to understand the mainstream user as the ensuing round of discussion that follows. From here on out, I'll benchmarks brought out the fact you really needed assume you know the basics of pipelined execution multithreaded applications to get the full benefits of and are familiar with the general architectural two processors. division between a processor's front end and its execution core. If these terms are mysterious to you, Even though the PC enthusiast SMP craze has long then you might want to reach way back and check since died down and, in an odd twist of fate, Mac out my "Into the K7" article, as well as some of my users are now many times more likely to be sporting other work on the P4 and G4e. an SMP rig than their x86-using peers, multithreading is once again about to increase in Conventional multithreading importance for PC users. Intel's next major IA-32 processor release, codenamed Prescott, will include Quite a bit of what a CPU does is illusion. For a feature called simultaneous multithreading instance, modern out-of-order processor (SMT), also known as hyper-threading. To take architectures don't actually execute code full advantage of SMT, applications will need to be sequentially in the order in which it was written. I've multithreaded; and just like with SMP, the higher covered the topic of out-of-order execution (OOE) the degree of multithreading the more performance in previous articles, so I won't rehash all that here. an application can wring out of Prescott's hardware. I'll just note that an OOE architecture takes code that was written and compiled to be executed in a Intel actually already uses SMT in a shipping specific order, reschedules the sequence of design: the Pentium 4 Xeon. Near the end of this instructions (if possible) so that they make article we'll take a look at the way the Xeon maximum use of the processor resources, executes implements hyper-threading; this analysis should them, and then arranges them back in their original give us a pretty good idea of what's in store for order so that the results can be written out to Prescott. Also, it's rumored that the current crop of memory. To the programmer and the user, it looks Pentium 4's actually has SMT hardware built-in, it's as if an ordered, sequential stream of instructions just disabled. (If you add this to the rumor about went into the CPU and identically ordered, x86-64 support being present but disabled as well, sequential stream of computational results emerged. then you can get some idea of just how cautious Only the CPU knows in what order the program's Intel is when it comes to introducing new features. instructions were actually executed, and in that I'd kill to get my hands on a 2.8 GHz P4 with both respect the processor is like a black box to both the SMT and x86-64 support turned on.) programmer and the user. SMT, in a nutshell, allows the CPU to do what most The same kind of sleight-of-hand happens when you users think it's doing anyway: run more than one run multiple programs at once, except this time the http://www.arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html operating system is also involved in the scam. To the front end, with the "back end"/"execution core" the end user, it appears as if the processor is containing only the execution units themselves and "running" more than one program at the same time, the retire logic. So in this article, the front end is the and indeed, there actually are multiple programs place where instructions are fetched, decoded, and loaded into memory. But the CPU can execute only re-ordered, and the execution core is where they're one of these programs at a time. The OS maintains actually executed and retired. the illusion of concurrency by rapidly switching between running programs at a fixed interval, called Preemptive multitasking vs. Cooperative a time slice. The time slice has to be small enough multitasking that the user doesn't notice any degradation in the usability and performance of the running programs, While I'm on this topic, I'll go ahead and take a brief and it has to be large enough that each program has moment to explain preemptive multitasking versus a sufficient amount of CPU time in which to get cooperative multitasking. Back in the bad old days, useful work done. Most modern operating systems which wasn't so long ago for Mac users, the OS include a way to change the size of an individual relied on each program to give up voluntarily the program's time slice. So a program with a larger CPU after its time slice was up. This scheme was time slice gets more actual execution time on the called "cooperative multitasking" because it relied CPU relative to its lower priority peers, and hence it on the running programs to cooperate with each runs faster. (On a related note, this brings to mind other and with the OS in order to share the CPU one of my favorite .sig file quotes: "A message from among themselves in a fair and equitable manner. the system administrator: 'I've upped my priority. Sure, there was a designated time slice in which Now up yours.'") each program was supposed to execute, and but the rules weren't strictly enforced by the OS. In the end, Clarification of terms: "running" vs. we all know what happens when you rely on people "executing," and "front end" vs. "execution and industries to regulate themselves--you wind up core." with a small number of ill-behaved parties who don't play by the rules and who make things miserable for For our purposes in this article, "running" does not everyone else. In cooperative multitasking systems, equal "executing." I want to set up this some programs would monopolize the CPU and not terminological distinction near the outset of the let it go, with the result that the whole system would article for clarity's sake. So for the remainder of this grind to a halt. article, we'll say that a program has been launched and is "running" when its code (or some portion of Preemptive multi-tasking, in contrast, strictly its code) is loaded into main memory, but it isn't enforces the rules and kicks each program off the actually executing until that code has been loaded CPU once its time slice is up. Coupled with into the processor. Another way to think of this preemptive multi-tasking is memory protection, would be to say that the OS runs programs, and the which means that the OS also makes sure that each processor executes them. program uses the memory space allocated to it and it alone. In a modern, preemptively multi-tasked and The other thing that I should clarify before protected memory OS each program is walled off proceeding is that the way that I divide up the from the others so that it believes it's the only processor in this and other articles differs from the program on the system. way that Intel's literature divides it. Intel will describe its processors as having an "in-order front Each program has a mind of its own end" and an "out-of-order execution engine." This is because for Intel, the front-end consists mainly of The OS and system hardware not only cooperate to the instruction fetcher and decoder, while all of the fool the user about the true mechanics of multi- register rename logic, out-of-order scheduling logic, tasking, but they cooperate to fool each running and so on is considered to be part of the "back end" program as well. While the user thinks that all of the or "execution core." The way that I and many others currently running programs are being executed draw the line between front-end and back-end places simultaneously, each of those programs thinks that it all of the out-of-order and register rename logic in has a monopoly on the CPU and memory. As far as http://www.arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html a running program is concerned, it's the only four-instruction limit.
Recommended publications
  • A Comprehensive Review for Central Processing Unit Scheduling Algorithm

    A Comprehensive Review for Central Processing Unit Scheduling Algorithm

    IJCSI International Journal of Computer Science Issues, Vol. 10, Issue 1, No 2, January 2013 ISSN (Print): 1694-0784 | ISSN (Online): 1694-0814 www.IJCSI.org 353 A Comprehensive Review for Central Processing Unit Scheduling Algorithm Ryan Richard Guadaña1, Maria Rona Perez2 and Larry Rutaquio Jr.3 1 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines 2 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines 3 Computer Studies and System Department, University of the East Caloocan City, 1400, Philippines Abstract when an attempt is made to execute a program, its This paper describe how does CPU facilitates tasks given by a admission to the set of currently executing processes is user through a Scheduling Algorithm. CPU carries out each either authorized or delayed by the long-term scheduler. instruction of the program in sequence then performs the basic Second is the Mid-term Scheduler that temporarily arithmetical, logical, and input/output operations of the system removes processes from main memory and places them on while a scheduling algorithm is used by the CPU to handle every process. The authors also tackled different scheduling disciplines secondary memory (such as a disk drive) or vice versa. and examples were provided in each algorithm in order to know Last is the Short Term Scheduler that decides which of the which algorithm is appropriate for various CPU goals. ready, in-memory processes are to be executed. Keywords: Kernel, Process State, Schedulers, Scheduling Algorithm, Utilization. 2. CPU Utilization 1. Introduction In order for a computer to be able to handle multiple applications simultaneously there must be an effective way The central processing unit (CPU) is a component of a of using the CPU.
  • 1 Introduction

    1 Introduction

    Cambridge University Press 978-0-521-76992-1 - Microprocessor Architecture: From Simple Pipelines to Chip Multiprocessors Jean-Loup Baer Excerpt More information 1 Introduction Modern computer systems built from the most sophisticated microprocessors and extensive memory hierarchies achieve their high performance through a combina- tion of dramatic improvements in technology and advances in computer architec- ture. Advances in technology have resulted in exponential growth rates in raw speed (i.e., clock frequency) and in the amount of logic (number of transistors) that can be put on a chip. Computer architects have exploited these factors in order to further enhance performance using architectural techniques, which are the main subject of this book. Microprocessors are over 30 years old: the Intel 4004 was introduced in 1971. The functionality of the 4004 compared to that of the mainframes of that period (for example, the IBM System/370) was minuscule. Today, just over thirty years later, workstations powered by engines such as (in alphabetical order and without specific processor numbers) the AMD Athlon, IBM PowerPC, Intel Pentium, and Sun UltraSPARC can rival or surpass in both performance and functionality the few remaining mainframes and at a much lower cost. Servers and supercomputers are more often than not made up of collections of microprocessor systems. It would be wrong to assume, though, that the three tenets that computer archi- tects have followed, namely pipelining, parallelism, and the principle of locality, were discovered with the birth of microprocessors. They were all at the basis of the design of previous (super)computers. The advances in technology made their implementa- tions more practical and spurred further refinements.
  • The Different Unix Contexts

    The Different Unix Contexts

    The different Unix contexts • User-level • Kernel “top half” - System call, page fault handler, kernel-only process, etc. • Software interrupt • Device interrupt • Timer interrupt (hardclock) • Context switch code Transitions between contexts • User ! top half: syscall, page fault • User/top half ! device/timer interrupt: hardware • Top half ! user/context switch: return • Top half ! context switch: sleep • Context switch ! user/top half Top/bottom half synchronization • Top half kernel procedures can mask interrupts int x = splhigh (); /* ... */ splx (x); • splhigh disables all interrupts, but also splnet, splbio, splsoftnet, . • Masking interrupts in hardware can be expensive - Optimistic implementation – set mask flag on splhigh, check interrupted flag on splx Kernel Synchronization • Need to relinquish CPU when waiting for events - Disk read, network packet arrival, pipe write, signal, etc. • int tsleep(void *ident, int priority, ...); - Switches to another process - ident is arbitrary pointer—e.g., buffer address - priority is priority at which to run when woken up - PCATCH, if ORed into priority, means wake up on signal - Returns 0 if awakened, or ERESTART/EINTR on signal • int wakeup(void *ident); - Awakens all processes sleeping on ident - Restores SPL a time they went to sleep (so fine to sleep at splhigh) Process scheduling • Goal: High throughput - Minimize context switches to avoid wasting CPU, TLB misses, cache misses, even page faults. • Goal: Low latency - People typing at editors want fast response - Network services can be latency-bound, not CPU-bound • BSD time quantum: 1=10 sec (since ∼1980) - Empirically longest tolerable latency - Computers now faster, but job queues also shorter Scheduling algorithms • Round-robin • Priority scheduling • Shortest process next (if you can estimate it) • Fair-Share Schedule (try to be fair at level of users, not processes) Multilevel feeedback queues (BSD) • Every runnable proc.
  • Instruction Latencies and Throughput for AMD and Intel X86 Processors

    Instruction Latencies and Throughput for AMD and Intel X86 Processors

    Instruction latencies and throughput for AMD and Intel x86 processors Torbj¨ornGranlund 2019-08-02 09:05Z Copyright Torbj¨ornGranlund 2005{2019. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. This report is work-in-progress. A newer version might be available here: https://gmplib.org/~tege/x86-timing.pdf In this short report we present latency and throughput data for various x86 processors. We only present data on integer operations. The data on integer MMX and SSE2 instructions is currently limited. We might present more complete data in the future, if there is enough interest. There are several reasons for presenting this report: 1. Intel's published data were in the past incomplete and full of errors. 2. Intel did not publish any data for 64-bit operations. 3. To allow straightforward comparison of an important aspect of AMD and Intel pipelines. The here presented data is the result of extensive timing tests. While we have made an effort to make sure the data is accurate, the reader is cautioned that some errors might have crept in. 1 Nomenclature and notation LNN means latency for NN-bit operation.TNN means throughput for NN-bit operation. The term throughput is used to mean number of instructions per cycle of this type that can be sustained. That implies that more throughput is better, which is consistent with how most people understand the term. Intel use that same term in the exact opposite meaning in their manuals. The notation "P6 0-E", "P4 F0", etc, are used to save table header space.
  • Introduction to Multi-Threading and Vectorization Matti Kortelainen Larsoft Workshop 2019 25 June 2019 Outline

    Introduction to Multi-Threading and Vectorization Matti Kortelainen Larsoft Workshop 2019 25 June 2019 Outline

    Introduction to multi-threading and vectorization Matti Kortelainen LArSoft Workshop 2019 25 June 2019 Outline Broad introductory overview: • Why multithread? • What is a thread? • Some threading models – std::thread – OpenMP (fork-join) – Intel Threading Building Blocks (TBB) (tasks) • Race condition, critical region, mutual exclusion, deadlock • Vectorization (SIMD) 2 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading Image courtesy of K. Rupp 3 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization Motivations for multithreading • One process on a node: speedups from parallelizing parts of the programs – Any problem can get speedup if the threads can cooperate on • same core (sharing L1 cache) • L2 cache (may be shared among small number of cores) • Fully loaded node: save memory and other resources – Threads can share objects -> N threads can use significantly less memory than N processes • If smallest chunk of data is so big that only one fits in memory at a time, is there any other option? 4 6/25/19 Matti Kortelainen | Introduction to multi-threading and vectorization What is a (software) thread? (in POSIX/Linux) • “Smallest sequence of programmed instructions that can be managed independently by a scheduler” [Wikipedia] • A thread has its own – Program counter – Registers – Stack – Thread-local memory (better to avoid in general) • Threads of a process share everything else, e.g. – Program code, constants – Heap memory – Network connections – File handles
  • The Von Neumann Computer Model 5/30/17, 10:03 PM

    The Von Neumann Computer Model 5/30/17, 10:03 PM

    The von Neumann Computer Model 5/30/17, 10:03 PM CIS-77 Home http://www.c-jump.com/CIS77/CIS77syllabus.htm The von Neumann Computer Model 1. The von Neumann Computer Model 2. Components of the Von Neumann Model 3. Communication Between Memory and Processing Unit 4. CPU data-path 5. Memory Operations 6. Understanding the MAR and the MDR 7. Understanding the MAR and the MDR, Cont. 8. ALU, the Processing Unit 9. ALU and the Word Length 10. Control Unit 11. Control Unit, Cont. 12. Input/Output 13. Input/Output Ports 14. Input/Output Address Space 15. Console Input/Output in Protected Memory Mode 16. Instruction Processing 17. Instruction Components 18. Why Learn Intel x86 ISA ? 19. Design of the x86 CPU Instruction Set 20. CPU Instruction Set 21. History of IBM PC 22. Early x86 Processor Family 23. 8086 and 8088 CPU 24. 80186 CPU 25. 80286 CPU 26. 80386 CPU 27. 80386 CPU, Cont. 28. 80486 CPU 29. Pentium (Intel 80586) 30. Pentium Pro 31. Pentium II 32. Itanium processor 1. The von Neumann Computer Model Von Neumann computer systems contain three main building blocks: The following block diagram shows major relationship between CPU components: the central processing unit (CPU), memory, and input/output devices (I/O). These three components are connected together using the system bus. The most prominent items within the CPU are the registers: they can be manipulated directly by a computer program. http://www.c-jump.com/CIS77/CPU/VonNeumann/lecture.html Page 1 of 15 IPR2017-01532 FanDuel, et al.
  • Parallel Programming

    Parallel Programming

    Parallel Programming Parallel Programming Parallel Computing Hardware Shared memory: multiple cpus are attached to the BUS all processors share the same primary memory the same memory address on different CPU’s refer to the same memory location CPU-to-memory connection becomes a bottleneck: shared memory computers cannot scale very well Parallel Programming Parallel Computing Hardware Distributed memory: each processor has its own private memory computational tasks can only operate on local data infinite available memory through adding nodes requires more difficult programming Parallel Programming OpenMP versus MPI OpenMP (Open Multi-Processing): easy to use; loop-level parallelism non-loop-level parallelism is more difficult limited to shared memory computers cannot handle very large problems MPI(Message Passing Interface): require low-level programming; more difficult programming scalable cost/size can handle very large problems Parallel Programming MPI Distributed memory: Each processor can access only the instructions/data stored in its own memory. The machine has an interconnection network that supports passing messages between processors. A user specifies a number of concurrent processes when program begins. Every process executes the same program, though theflow of execution may depend on the processors unique ID number (e.g. “if (my id == 0) then ”). ··· Each process performs computations on its local variables, then communicates with other processes (repeat), to eventually achieve the computed result. In this model, processors pass messages both to send/receive information, and to synchronize with one another. Parallel Programming Introduction to MPI Communicators and Groups: MPI uses objects called communicators and groups to define which collection of processes may communicate with each other.
  • Lecture Notes

    Lecture Notes

    Lecture #4-5: Computer Hardware (Overview and CPUs) CS106E Spring 2018, Young In these lectures, we begin our three-lecture exploration of Computer Hardware. We start by looking at the different types of computer components and how they interact during basic computer operations. Next, we focus specifically on the CPU (Central Processing Unit). We take a look at the Machine Language of the CPU and discover it’s really quite primitive. We explore how Compilers and Interpreters allow us to go from the High-Level Languages we are used to programming to the Low-Level machine language actually used by the CPU. Most modern CPUs are multicore. We take a look at when multicore provides big advantages and when it doesn’t. We also take a short look at Graphics Processing Units (GPUs) and what they might be used for. We end by taking a look at Reduced Instruction Set Computing (RISC) and Complex Instruction Set Computing (CISC). Stanford President John Hennessy won the Turing Award (Computer Science’s equivalent of the Nobel Prize) for his work on RISC computing. Hardware and Software: Hardware refers to the physical components of a computer. Software refers to the programs or instructions that run on the physical computer. - We can entirely change the software on a computer, without changing the hardware and it will transform how the computer works. I can take an Apple MacBook for example, remove the Apple Software and install Microsoft Windows, and I now have a Window’s computer. - In the next two lectures we will focus entirely on Hardware.
  • Comparing Systems Using Sample Data

    Comparing Systems Using Sample Data

    Operating System and Process Monitoring Tools Arik Brooks, [email protected] Abstract: Monitoring the performance of operating systems and processes is essential to debug processes and systems, effectively manage system resources, making system decisions, and evaluating and examining systems. These tools are primarily divided into two main categories: real time and log-based. Real time monitoring tools are concerned with measuring the current system state and provide up to date information about the system performance. Log-based monitoring tools record system performance information for post-processing and analysis and to find trends in the system performance. This paper presents a survey of the most commonly used tools for monitoring operating system and process performance in Windows- and Unix-based systems and describes the unique challenges of real time and log-based performance monitoring. See Also: Table of Contents: 1. Introduction 2. Real Time Performance Monitoring Tools 2.1 Windows-Based Tools 2.1.1 Task Manager (taskmgr) 2.1.2 Performance Monitor (perfmon) 2.1.3 Process Monitor (pmon) 2.1.4 Process Explode (pview) 2.1.5 Process Viewer (pviewer) 2.2 Unix-Based Tools 2.2.1 Process Status (ps) 2.2.2 Top 2.2.3 Xosview 2.2.4 Treeps 2.3 Summary of Real Time Monitoring Tools 3. Log-Based Performance Monitoring Tools 3.1 Windows-Based Tools 3.1.1 Event Log Service and Event Viewer 3.1.2 Performance Logs and Alerts 3.1.3 Performance Data Log Service 3.2 Unix-Based Tools 3.2.1 System Activity Reporter (sar) 3.2.2 Cpustat 3.3 Summary of Log-Based Monitoring Tools 4.
  • Real-Time Performance During CUDA™ a Demonstration and Analysis of Redhawk™ CUDA RT Optimizations

    Real-Time Performance During CUDA™ a Demonstration and Analysis of Redhawk™ CUDA RT Optimizations

    A Concurrent Real-Time White Paper 2881 Gateway Drive Pompano Beach, FL 33069 (954) 974-1700 www.concurrent-rt.com Real-Time Performance During CUDA™ A Demonstration and Analysis of RedHawk™ CUDA RT Optimizations By: Concurrent Real-Time Linux® Development Team November 2010 Overview There are many challenges to creating a real-time Linux distribution that provides guaranteed low process-dispatch latencies and minimal process run-time jitter. Concurrent Real Time’s RedHawk Linux distribution meets and exceeds these challenges, providing a hard real-time environment on many qualified hardware configurations, even in the presence of a heavy system load. However, there are additional challenges faced when guaranteeing real-time performance of processes while CUDA applications are simultaneously running on the system. The proprietary CUDA driver supplied by NVIDIA® frequently makes demands upon kernel resources that can dramatically impact real-time performance. This paper discusses a demonstration application developed by Concurrent to illustrate that RedHawk Linux kernel optimizations allow hard real-time performance guarantees to be preserved even while demanding CUDA applications are running. The test results will show how RedHawk performance compares to CentOS performance running the same application. The design and implementation details of the demonstration application are also discussed in this paper. Demonstration This demonstration features two selectable real-time test modes: 1. Jitter Mode: measure and graph the run-time jitter of a real-time process 2. PDL Mode: measure and graph the process-dispatch latency of a real-time process While the demonstration is running, it is possible to switch between these different modes at any time.
  • A Simple Chargeback System for SAS® Applications Running on UNIX and Linux Servers

    A Simple Chargeback System for SAS® Applications Running on UNIX and Linux Servers

    SAS Global Forum 2007 Systems Architecture Paper: 194-2007 A Simple Chargeback System For SAS® Applications Running on UNIX and Linux Servers Michael A. Raithel, Westat, Rockville, MD Abstract Organizations that run SAS on UNIX and Linux servers often have a need to measure overall SAS usage and to charge the projects and users who utilize the servers. This allows an organization to pay for the hardware, software, and labor necessary to maintain and run these types of shared servers. However, performance management and accounting software is normally expensive. Purchasing such software, configuring it, and managing it may be prohibitive in terms of cost and in terms of having staff with the right skill sets to do so. Consequently, many organizations with UNIX or Linux servers do not have a reliable way to measure the overall use of SAS software and to charge individuals and projects for its use. This paper presents a simple methodology for creating a chargeback system on UNIX and Linux servers. It uses basic accounting programs found in the UNIX and Linux operating systems, and exploits them using SAS software. The paper presents an overview of the UNIX/Linux “sa” command and the basic accounting system. Then, it provides a SAS program that utilizes this command to capture and store monthly SAS usage statistics. The paper presents a second SAS program that reads the monthly SAS usage SAS data set and creates both a chargeback report and a general usage report. After reading this paper, you should be able to easily adapt the sample SAS programs to run on servers in your own environment.
  • Unit: 4 Processes and Threads in Distributed Systems

    Unit: 4 Processes and Threads in Distributed Systems

    Unit: 4 Processes and Threads in Distributed Systems Thread A program has one or more locus of execution. Each execution is called a thread of execution. In traditional operating systems, each process has an address space and a single thread of execution. It is the smallest unit of processing that can be scheduled by an operating system. A thread is a single sequence stream within in a process. Because threads have some of the properties of processes, they are sometimes called lightweight processes. In a process, threads allow multiple executions of streams. Thread Structure Process is used to group resources together and threads are the entities scheduled for execution on the CPU. The thread has a program counter that keeps track of which instruction to execute next. It has registers, which holds its current working variables. It has a stack, which contains the execution history, with one frame for each procedure called but not yet returned from. Although a thread must execute in some process, the thread and its process are different concepts and can be treated separately. What threads add to the process model is to allow multiple executions to take place in the same process environment, to a large degree independent of one another. Having multiple threads running in parallel in one process is similar to having multiple processes running in parallel in one computer. Figure: (a) Three processes each with one thread. (b) One process with three threads. In former case, the threads share an address space, open files, and other resources. In the latter case, process share physical memory, disks, printers and other resources.