Processes• Recall that a process in

Processes
• Recall that a process includes many things
• An address space (defining all the code and data pages)
• OS resources (e.g., open files) and accounting information
• Execution state (PC, SP, regs, etc.)
• Creating a new process is costly because of all of the data
structures that must be allocated and initialized
• Recall struct proc in Solaris
• …which does not even include page tables, perhaps TLB
flushing, etc.
• Communicating between processes is costly because most
communication goes through the OS
• Overhead of system calls and copying data



Parallel Programs
• To execute these programs we need to
• Create several processes that execute in parallel
• Cause each to map to the same address space to share data
• They are all part of the same computation
• Have the OS schedule these processes in parallel
• This situation is very inefficient
• Space: PCB, page tables, etc.
• Time: create data structures, fork and copy addr space, etc.
• Solutions: possible to have more efficient, yet cooperative
“processes”?


Rethinking Processes
• What is similar in these cooperating processes?
• They all share the same code and data (address space)
• They all share the same privileges
• They all share the same resources (files, sockets, etc.)
• What don’t they share?
• Each has its own execution state: PC, SP, and registers
• Key idea: Why don’t we separate the concept of a process from
its execution state?
• Process: address space, privileges, resources, etc.
• Execution state: PC, SP, registers
• Exec state also called thread of control, or thread


Threads
• Modern OSes (Mac, Windows, modern Unix) separate
the concepts of processes and threads
• The thread defines a sequential execution stream within a
process (PC, SP, registers)
• The process defines the address space and general process
attributes (everything but threads of execution)
• A thread is bound to a single process
• Processes, however, can have multiple threads
• Threads become the unit of scheduling
• Processes are now the containers in which threads execute



Analogy:
• Process:
• Hire 4 software engineers to work on 4 projects
• Thread:
• Have one engineer to work on 4 projects


The thread model
• Shared information
• Processor info: parent process, time, etc
• Memory: segments, page table, and stats, etc
• I/O and file: communication ports, directories and file descriptors, etc
• Private state
• Registers
• Program counter
• Execution stack
• State (ready, running and blocked)
• Why?
• Each thread execute separately


Kernel-Level Threads
• We have taken the execution aspect of a process and
separated it out into threads
• To make concurrency cheaper
• As such, the OS now manages threads and processes
• All thread operations are implemented in the kernel
• The OS schedules all of the threads in the system
• OS-managed threads are called kernel-level threads or
lightweight processes
• Windows: threads
• Solaris: lightweight processes (LWP)
• POSIX Threads (pthreads): PTHREAD_SCOPE_SYSTEM



Kernel-level Thread
Limitations
• Kernel-level threads make concurrency much cheaper than
processes
• Much less state to allocate and initialize
• However, for fine-grained concurrency, kernel-level threads
still suffer from too much overhead
• Thread operations still require system calls
• Ideally, want thread operations to be as fast as a procedure call
• For such fine-grained concurrency, need even “cheaper”
threads


User-Level Threads
• To make threads cheap and fast, they need to be
implemented at user level
• Kernel-level threads are managed by the OS
• User-level threads are managed entirely by the run-time system
(user-level library)
• User-level threads are small and fast
• A thread is simply represented by a PC, registers, stack, and
small thread control block (TCB)
• Creating a new thread, switching between threads, and
synchronizing threads are done via procedure call
• No kernel involvement
• User-level thread operations 100x faster than kernel threads
• pthreads: PTHREAD_SCOPE_PROCESS


User-level Thread Limitations
• But, user-level threads are not a perfect solution
• As with everything else, they are a tradeoff
• User-level threads are invisible to the OS
• They are not well integrated with the OS
• As a result, the OS can make poor decisions
• Scheduling a process with idle threads
• Blocking a process whose thread initiated an I/O, even though the
process has other threads that can execute
• Solving this requires communication between the kernel and
the user-level thread manager


Kernel- vs. User-level Threads
• Kernel-level threads
• Integrated with OS (informed scheduling)
• Slow to create, manipulate, synchronize
• User-level threads
• Fast to create, manipulate, synchronize
• Not integrated with OS (uninformed scheduling)
• Understanding the differences between kernel- and
user-level threads is important
• For programming (correctness, performance)
• For test-taking



Kernel- and User-level
Threads
• Or use both kernel- and user-level threads
• Can associate a user-level thread with a kernel-level thread
• Or, multiplex user-level threads on top of kernel-level
threads
• Java Virtual Machine (JVM)
• Java threads are user-level threads
• On older Unix, only one “kernel thread” per process
• Multiplex all Java threads on this one kernel thread
• On Windows NT, modern Unix
• Can multiplex Java threads on multiple kernel threads
• Can have more Java threads than kernel threads


Implementing Threads
• Implementing threads has a number of issues
• Interface
• Context switch
• Preemptive vs. Non-preemptive
• What do they mean?
• Scheduling
• Synchronization (next lecture)
• Focus on user-level threads
• Kernel-level threads are similar to original process
management and implementation in the OS



Sample Thread Interface
• thread_create(procedure_t, arg)
• Create a new thread of control
• Start executing procedure_t
• thread_yield()
• Voluntarily give up the processor
• thread_exit()
• Terminate the calling thread; also thread_destroy
• thread_join(target_thread)
• Suspend the execution of calling thread until target_thread
terminates



Thread Scheduling
• For user-level thread: scheduling occurs entirely in user-space
• The thread scheduler determines when a thread runs
• It uses queues to keep track of what threads are doing
• Just like the OS and processes
• But it is implemented at user-level in a library
• Run queue: Threads currently running (usually one)
• Ready queue: Threads ready to run
• Are there wait queues?



Sample Thread Interface
• thread_create(procedure_t, arg)
• Create a new thread of control
• Start executing procedure_t
• thread_yield()
• Voluntarily give up the processor
• thread_exit()
• Terminate the calling thread; also thread_destroy
• thread_join(target_thread)
• Suspend the execution of calling thread until target_thread
terminates


Thread Context Switch
• The context switch routine does all of the magic
• Saves context of the currently running thread (old_thread)
• Push all machine state onto its stack
• Restores context of the next thread
• Pop all machine state from the next thread’s stack
• The next thread becomes the current thread
• Return to caller as new thread
• This is all done in assembly language
• See arch/mips/mips/switch.S in OS161 (kernel thread
implementation)



Wait a minute
• Non-preemptive threads have to voluntarily give up
CPU
• Only voluntary calls to thread_yield(), or thread_exit()
causes a context switch
• What if one thread never release the CPU (never calls
thread_yield())?
• We need preemptive user-level thread scheduling


Preemptive Scheduling
• Preemptive scheduling causes an involuntary context switch
• Need to regain control of processor asynchronously
• How?
• Use timer interrupt
• Timer interrupt handler forces current thread to “call”
thread_yield
• How


Process vs. threads
• Multithreading is only an option for “cooperative tasks”
• Trust and sharing
• Process
• Strong isolation but poor performance
• Thread
• Good performance but share too much
• Example: web browsers
• Safari: multithreading
• one webpage can crash entire Safari
• Google Chrome: each tab has its own process


Threads Summary
• The operating system as a large multithreaded program
• Each process executes as a thread within the OS
• Multithreading is also very useful for applications
• Efficient multithreading requires fast primitives
• Processes are too heavyweight
• Solution is to separate threads from processes
• Kernel-level threads much better, but still significant overhead
• User-level threads even better, but not well integrated with OS
• Now, how do we get our threads to correctly cooperate with
each other?
• Synchronization…

ผลลัพธ์ (ไทย) 1:

กระบวนการ•นึกว่า กระบวนการประกอบด้วยสิ่งต่าง ๆ มากมาย•เป็นพื้นที่ที่อยู่ (การกำหนดรหัสและข้อมูลเพจทั้งหมด)• OS ทรัพยากร (เช่น เปิดแฟ้ม) และบัญชีข้อมูล•สถานะการดำเนินการ (PC, SP, regs ฯลฯ)•สร้างกระบวนการใหม่จะเสียค่าใช้จ่ายเนื่องจากข้อมูลทั้งหมดโครงสร้างที่ต้องปันส่วน และเริ่มต้น•เรียกคืน struct กระบวนการในโซลาริส•... .which ไม่ได้รวมตารางหน้า TLB ทีลบ ฯลฯ•ติดต่อสื่อสารระหว่างกระบวนเป็นค่าใช้จ่ายเนื่องจากส่วนใหญ่สื่อสารไปถึงระบบปฏิบัติการ•ค่าใช้จ่ายในระบบโทรศัพท์และการคัดลอกข้อมูลโปรแกรมแบบขนาน•เพื่อเรียกใช้โปรแกรมเหล่านี้เราจำเป็นต้อง•สร้างกระบวนการต่าง ๆ ที่ดำเนินการควบคู่กัน•สาเหตุแต่ละแมปที่อยู่พื้นที่เดียวกันเพื่อใช้ข้อมูลร่วมกัน•เป็นส่วนหนึ่งของการคำนวณเดียวกัน•มีระบบปฏิบัติการที่จัดกำหนดการกระบวนการเหล่านี้ควบคู่กัน•สถานการณ์นี้จะต่ำมาก•เนื้อที่: PCB ตารางหน้า ฯลฯ•เวลา: สร้างโครงสร้างข้อมูล ส้อมและคัดลอกที่อยู่พื้นที่ ฯลฯ•โซลูชั่น: จะต้องมีประสิทธิภาพมากขึ้น สหกรณ์ยัง"กระบวนการ" หรือไม่กระบวนการคิด•สิ่งคล้ายเหล่านี้ร่วมมือดำเนินการหรือไม่•พวกเขาทั้งหมดใช้รหัสและข้อมูล (พื้นที่) เหมือนกันพวกเขาทั้งหมดใช้สิทธิ์เดียวกัน••พวกเขาทั้งหมดใช้ทรัพยากรเดียวกัน (แฟ้ม ซ็อกเก็ต ฯลฯ)•ที่ไม่พวกเขาใช้ร่วมกันหรือไม่•มีสถานะการดำเนินการของตัวเอง: PC, SP และทะเบียน•คิดคีย์: ทำไมไม่เราแยกแนวความคิดของกระบวนการจากสถานะการดำเนินการหรือไม่•กระบวนการ: ว่าง สิทธิ์ ทรัพยากร และอื่น ๆ•สถานะการดำเนินการ: PC, SP ลงทะเบียน•รัฐ exec เรียกว่าเธรดของตัวควบคุม หรือหัวข้อหัวข้อ•แยก OSes สมัย (Mac, Windows, Unix สมัย)แนวคิดของกระบวนการและหัวข้อ•หัวข้อกำหนดกระแสการดำเนินการตามลำดับภายในเป็นกระบวนการ (PC, SP ลงทะเบียน)•การกำหนดพื้นที่และกระบวนการทั่วไปแอตทริบิวต์ (ทุกอย่างแต่หัวข้อของการดำเนินการ)หัวข้อ• A กับกระบวนการหนึ่ง•กระบวนการ อย่างไรก็ตาม ได้หลายหัวข้อหัวข้อ•กลายเป็น หน่วยของการวางแผน•กระบวนการก็เก็บเธรดที่เรียกใช้เปรียบเทียบ:•กระบวนการ:•จ้างวิศวกรซอฟต์แวร์ 4 การทำงานในโครงการ 4•หัวข้อ:•มีวิศวกรหนึ่งในการทำงานในโครงการ 4รูปแบบหัวข้อ•ร่วมข้อมูล•ตัวประมวลผลข้อมูล: หลักการ เวลา ฯลฯ•หน่วยความจำ: เซ็กเมนต์ หน้า โต๊ะ และสถิติ ฯลฯ• I/O และแฟ้ม: พอร์ตการสื่อสาร ไดเรกทอรี และตัวแสดงรายละเอียดแฟ้ม ฯลฯ•สถานะส่วนตัว•การลงทะเบียน•โปรแกรมเคาน์เตอร์•การดำเนินการกองซ้อน•รัฐ (พร้อม รัน และถูกบล็อค)•ทำไม•แต่ละหัวข้อปฏิบัติแยกต่างหากเธรดระดับเคอร์เนล•เรามีดำเนินการด้านการดำเนินการของกระบวนการ และแบ่งออกเป็นหัวข้อ•เพื่อทำให้เกิดราคาถูกกว่า•เช่น OS ตอนนี้จัดการหัวข้อและกระบวนการ•ดำเนินงานเธรดทั้งหมดจะดำเนินการในเคอร์เนล•ระบบปฏิบัติการที่จัดกำหนดการเธรดทั้งหมดในระบบ•จัดการ OS กระทู้เรียกว่าเธรดระดับเคอร์เนล หรือกระบวนการที่มีน้ำหนักเบา• Windows: หัวข้อ•โซลาริส: กระบวนการน้ำหนักเบา (LWP)•กระทู้ POSIX (pthreads): PTHREAD_SCOPE_SYSTEM เธรดระดับเคอร์เนลข้อจำกัดหัวข้อ•ระดับ kernel ให้เกิดมากถูกกว่ากระบวนการ•มากน้อยสถานะ การปันส่วนเริ่มต้น•อย่างไรก็ตาม สำหรับทรายแป้งละเอียดเกิด เธรดระดับเคอร์เนลยัง ต้องทนทุกข์ทรมานจากเหนือศีรษะมากเกินไป•หัวข้อการดำเนินงานยังต้องเรียกระบบ•ห้อง ต้องการหัวข้อการดำเนินงานให้รวดเร็วที่เรียกขั้นตอน•สำหรับเกิดเช่นทรายแป้งละเอียด จำเป็นแม้กระทั่ง "ถูกกว่า"หัวข้อเธรดระดับผู้ใช้•เพื่อให้กระทู้ราคา และรวดเร็ว พวกเขาจำเป็นต้องดำเนินการในระดับผู้ใช้•ระดับ kernel กระทู้จะถูกจัดการ โดยระบบปฏิบัติการ•เธรดระดับผู้ใช้จะถูกจัดการทั้งหมด โดยระบบขณะทำงาน(ระดับของผู้ใช้ไลบรารี)เธรดระดับผู้ใช้•มีขนาดเล็ก และรวดเร็วหัวข้อ• A เพียงแสดง โดยพีซี ทะเบียน กอง และหัวข้อเล็กควบคุมบล็อก (TCB)•การสร้างหัวข้อใหม่ สลับระหว่างหัวข้อ และหัวข้อให้ตรงกันเสร็จสิ้นผ่านการเรียกขั้นตอน•ไม่มีส่วนร่วมของเคอร์เนล•เธรดระดับผู้ใช้งาน 100 x เร็วกว่ากระทู้เคอร์เนล• pthreads: PTHREAD_SCOPE_PROCESS เธรดระดับผู้ใช้ข้อจำกัด•แต่ เธรดระดับผู้ใช้ไม่ได้ เพราะ•กับทุกอย่างอื่น พวกเขาเป็นยอมเธรดระดับผู้ใช้•ไม่เห็นระบบปฏิบัติการ•จะไม่ดีรวมกับระบบปฏิบัติการ•เป็นผล ระบบปฏิบัติสามารถตัดสินใจได้ดี•การ มีหัวข้อที่ไม่ได้ใช้งาน•บล็อกเธรดเริ่มต้นการ I/O ถึงแม้ว่ากระบวนการกระบวนการมีหัวข้ออื่นที่สามารถดำเนินการ•แก้นี้ต้องการสื่อสารระหว่างเคอร์เนล และเธรดระดับผู้ใช้ผู้จัดการเธรดเคอร์เนล - เทียบกับระดับผู้ใช้หัวข้อ•ระดับ kernel•รวมเข้ากับ OS (แผนทราบ)•ชะลอการสร้าง จัดการ การซิงโครไนส์•ผู้ใช้ระดับหัวข้อ•รวดเร็วสร้าง จัดการ ประสาน•ไม่รวมกับ OS (ไม่รู้วางแผน)•เข้าใจความแตกต่างระหว่างเมล็ด - และเธรดระดับผู้ใช้เป็นสำคัญ•การเขียนโปรแกรม (ความถูกต้อง ประสิทธิภาพการทำงาน)•สำหรับการทดสอบ เคอร์เนล และผู้ใช้ระดับหัวข้อ•ใช้เธรดเคอร์เนล และผู้ใช้ระดับทั้งสอง•สามารถเชื่อมโยงเธรดระดับผู้ใช้กับเธรดระดับเคอร์เนล• หรือ multiplex เธรดระดับผู้ใช้บนระดับ kernelหัวข้อ• Java Virtual Machine (JVM)หัวข้อ• Java มีเธรดระดับผู้ใช้•บน Unix รุ่นเก่า เพียงหนึ่ง "เธรดเคอร์เนล" ต่อกระบวนการ• Multiplex กระทู้จาวาทั้งหมดบนเธรดเคอร์เนลหนึ่งนี้•บน Windows NT, Unix ที่ทันสมัย•สามารถ multiplex หัวข้อ Java บนเธรดเคอร์เนลหลาย•สามารถกำหนดหัวข้อ Java เพิ่มเติมกว่ากระทู้เคอร์เนลใช้หัวข้อ•หัวข้อนำไปใช้มีปัญหา•อินเตอร์เฟซ•สลับบริบท• Preemptive เทียบกับที่ไม่ใช่ preemptive•ทำพวกเขาหมายถึงอะไร•การจัดกำหนดการ•ซิงโครไนซ์ (บรรยายถัดไป)•ความเธรดระดับผู้ใช้หัวข้อ•ระดับ kernel จะคล้ายกับกระบวนการเดิมจัดการและการใช้งานในระบบปฏิบัติการตัวอย่างหัวข้ออินเทอร์เฟซ• thread_create (procedure_t อาร์กิวเมนต์ของค่า)•สร้างหัวข้อใหม่ของตัวควบคุม•เริ่มดำเนิน procedure_t• thread_yield()•ด้วยความสมัครใจให้หน่วยประมวลผล• thread_exit()•สิ้นสุดการเธรดเรียก ยัง thread_destroy• thread_join(target_thread)•ระงับการดำเนินการเรียกด้ายจนถึง target_threadสิ้นสุดลงเธรดการจัดกำหนดการ•สำหรับเธรดระดับผู้ใช้: วางแผนเกิดขึ้นทั้งหมดในพื้นที่ผู้ใช้•กำหนดการหัวข้อกำหนดเวลาการทำงานของเธรด•ใช้คิวเพื่อติดตามกระทู้จะทำอะไร•เช่นเดียวกับระบบปฏิบัติการและกระบวนการ• แต่ก็จะดำเนินการในระดับผู้ใช้ในไลบรารี•รันคิว: เธรดกำลังเรียกใช้ (ปกติ)•พร้อมคิว: เธรดพร้อมที่จะรัน•มีคิวรอตัวอย่างหัวข้ออินเทอร์เฟซ• thread_create (procedure_t อาร์กิวเมนต์ของค่า)•สร้างหัวข้อใหม่ของตัวควบคุม•เริ่มดำเนิน procedure_t• thread_yield()•ด้วยความสมัครใจให้หน่วยประมวลผล• thread_exit()•สิ้นสุดการเธรดเรียก ยัง thread_destroy• thread_join(target_thread)•ระงับการดำเนินการเรียกด้ายจนถึง target_threadสิ้นสุดลงหัวข้อสลับบริบท•ขั้นตอนการสลับบริบทไม่มหัศจรรย์ทั้งหมด•บันทึกเนื้อหาของหัวข้อที่กำลังทำงานอยู่ (old_thread)•ผลักดันสถานะเครื่องทั้งหมดลงในกองซ้อนของ•คืนค่าเนื้อหาของหัวข้อถัดไป•ป๊อปสถานะเครื่องทั้งหมดจากกองซ้อนของเธรดถัดไป•หัวข้อถัดไปกลายเป็น เธรดปัจจุบัน•กลับไปเรียกเป็นหัวข้อใหม่•ทั้งหมดทำเช่นนี้ในภาษาแอสเซมบลี•ดู โค้ง/mips/mips/สลับ ใน OS161 (เธรดเคอร์เนลนำไปใช้) รอสักครู่หนึ่ง•ไม่ใช่ preemptive เธรดได้ให้ด้วยความสมัครใจซีพียู•เพียงสมัครใจเรียก thread_yield() หรือ thread_exit()ทำให้สวิตช์บริบท•ถ้าหนึ่งเธรดไม่ปล่อย CPU (ไม่เรียกthread_yield())•ที่เราต้องการจัดกำหนดการ preemptive เธรดระดับผู้ใช้การจัดกำหนดการ preemptive• Preemptive แผนทำสลับบริบทที่ทำการ•ต้องสามารถควบคุมประมวลผลแบบอะซิงโครนัส•วิธี•ใช้เวลาขัดจังหวะ•จับสัญญาณขัดจังหวะตัวจัดการกองกำลังเธรดปัจจุบัน "โทร"thread_yield•วิธีกระบวนการเทียบกับหัวข้อ•มัลติเธรดเป็นเพียงตัวเลือกสำหรับ "งานสหกรณ์"•ความน่าเชื่อถือและการใช้ร่วมกัน•กระบวนการ•แยกแรงแต่ประสิทธิภาพต่ำ•หัวข้อ•ประสิทธิภาพดีแต่ใช้มากเกินไป•ตัวอย่าง: เว็บเบราว์เซอร์•ซาฟารี: มัลติเธรด•หนึ่งเว็บเพจสามารถผิดพลาดทั้งซาฟารี•กูเกิลโครม: แต่ละแท็บมีกระบวนการของตนเอง สรุปหัวข้อ•ระบบปฏิบัติการเป็นโปรแกรมให้ใหญ่•ดำเนินการแต่ละกระบวนการเป็นเธรดภายใต้ระบบปฏิบัติการ•มัลติเธรดเป็นประโยชน์มากสำหรับการใช้งาน•มัลติเธรดประสิทธิภาพต้องนำอย่างรวดเร็วกระบวนการ•มีเฮฟวี่เวทมากเกินไป•แก้ปัญหาจะแยกหัวข้อจากกระบวนการ•ระดับ kernel กระทู้ดี โอเวอร์เฮดแต่ยังคงสำคัญเธรดระดับผู้ใช้•รวมดีกว่า แต่ไม่ดีกับระบบปฏิบัติการ•ในตอนนี้ วิธีทำเราได้หัวข้อของเราจะร่วมมือกับอย่างถูกต้องกันและกัน•ตรง...

ผลลัพธ์ (ไทย) 3:

กระบวนการ
- จำได้ว่ากระบวนการรวมถึงหลายสิ่ง
- ที่อยู่อวกาศ ( กำหนดรหัสและข้อมูลทุกหน้า )
- OS RESOURCES ( เปิดแฟ้มเช่น ) และข้อมูลบัญชีรัฐประหาร
- ( PC , SP , regs ฯลฯ )
- สร้างกระบวนการใหม่มีราคาแพงเพราะของทั้งหมดของข้อมูล
โครงสร้างที่ต้องจัดสรรและเริ่มต้นการเรียกคืนซอฟต์แวร์
-
proc ในโซลาริส- . . . . . . . ซึ่งไม่ได้รวมหน้าโต๊ะ บางที TLB

- ฟลัชชิง เป็นต้น การสื่อสารระหว่างกระบวนการราคาแพงเพราะที่สุด

บริการการสื่อสารผ่าน OS ค่าใช้จ่ายของระบบโทรศัพท์และการคัดลอกข้อมูล




- ขนานโปรแกรมเพื่อรันโปรแกรมเหล่านี้เราต้อง
- สร้างหลายกระบวนการที่ดำเนินการในแบบขนาน
- เพราะแต่ละแผนที่กับที่อยู่เดียวกันกับพื้นที่ที่จะแบ่งปันข้อมูล
- พวกเขาเป็นส่วนหนึ่งของบริการการคำนวณ
เดียวกันมี OS ตารางกระบวนการเหล่านี้ในแต่ละขนาน สถานการณ์นี้จะไม่ได้ผลมาก

บริการพื้นที่ : PCB , หน้าโต๊ะ , ฯลฯ
- เวลา : สร้างโครงสร้างข้อมูล ส้อมและคัดลอกพื้นที่บาป ฯลฯ
- โซลูชั่น : เป็นไปได้ที่จะมีประสิทธิภาพมากขึ้น แต่สหกรณ์
" กระบวนการ "



- ทบทวนกระบวนการอะไรที่คล้ายกันในเหล่านี้ประสานงานกระบวนการ ?
- พวกเขาทั้งหมดใช้รหัสเดียวกันและข้อมูล ( ที่อยู่พื้นที่ )
- พวกเขาทั้งหมดร่วมกันสิทธิประโยชน์
- พวกเขาทั้งหมดร่วมกันทรัพยากรเดียวกัน ( ไฟล์ , ซ็อกเก็ต ฯลฯ )
- สิ่งที่พวกเขาไม่แบ่งปัน ?
- แต่ละคนมีรัฐประหารของตัวเอง : PC , SP และลงทะเบียน
- คีย์คิด : ทำไมเราไม่แยกจากแนวคิดของกระบวนการรัฐประหาร
?
- กระบวนการ : ที่อยู่พื้นที่ อภิสิทธิ์ ทรัพยากร ฯลฯ
- การประหารรัฐ : PC , SP , ทะเบียน
- Exec สภาพที่เรียกว่าหัวข้อควบคุม หรือด้าย


กระทู้
- ทันสมัย oses ( Mac , Windows , ทันสมัย Unix ) แยก
แนวคิดกระบวนการและหัวข้อ
- หัวข้อกระแสการกำหนดลำดับภายใน
กระบวนการ ( PC , SP , ลงทะเบียน )
- กระบวนการกำหนดที่อยู่พื้นที่และกระบวนการทั่วไป
คุณลักษณะ ( ทุกอย่าง แต่กระทู้ของการประหารชีวิต )