การประสานเวลากระบวนการ Process Synchronization นงลักษณ์ พรมทอง วิเชษฐ์ พลายมาศ

Objectives เพื่อศึกษาแนวคิดพื้นฐานเกี่ยวกับการประสานเวลาของซีพียู ปัญหาและวิธีการแก้ไขเกี่ยวกับการประสานเวลา เพื่อให้รู้เกี่ยวกับแนวคิดพื้นฐานและความเป็นมาเกี่ยวกับการประสานเวลากระบวนการ ส่วนวิกฤติ ฮาร์ดแวร์ประสานเวลา เซมาฟอร์ เพื่อให้เข้าใจถึงปัญหาของการประสานเวลา และวิธีการแก้ไขโดยใช้ตัวเฝ้าสังเกต และภาวะติดตาย

Agenda Basic Concepts Scheduling Criteria Scheduling Algorithms Multiple-Processor Scheduling Real-Time Scheduling Algorithm Evaluation

Agenda: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions

Background การออกแบบระบบปฏิบัติการ คือการเกี่ยวข้องกับกระจัดการกระบวนการและเธรด ในสภาพแวดล้อมต่อไปนี้ มัลติโปรแกรมมิง (Multiprogramming) มัลติโพรเซสซิง (Multiprocessing) การประมวลผลแบบกระจาย (Distributed processing) หรือ คลัสเตอร์ (cluster) จำเป็นต้องออกแบบเรื่อง การจัดการภาวะพร้อมกัน (concurrency) การประสานเวลา (synchronization)

Background (2) ภาวะพร้อมกันมักเกิดขึ้นภายใต้สภาพแวดล้อมที่แตกต่างกัน ดังนี้ แอพพลิเคชันหลายชุด สภาพแวดล้อมแบบมัลติโปรแกรมมิงยินยอมให้แอพพลิเคชันหลายตัวสามารถกระทำการในเวลาเดียวกันได้ โครงสร้างของแอพพลิเคชัน ภายใต้แนวคิดของการออกแบบมอดุลาร์และโปรแกรมแบบโครงสร้าง บางแอพพลิเคชันสามารถทำงานได้อย่างมีประสิทธิภาพเมื่อมีการเรียกใช้กระบวนการร่วมกัน โครงสร้างระบบปฏิบัติการ ระบบปฏิบัติการสมัยใหม่ได้มีการออกแบบให้กลุ่มกระบวนการสามารถทำงานไปพร้อมๆ กันได้

Background (3) การเข้าถึงข้อมูลในเวลาพร้อมๆ กันอาจเป็นเหตุให้เกิดความขัดแย้งกันของข้อมูลได้ การดูแลให้ข้อมูลมีความสอดคล้องกันย่อมต้องอาศัยกลไกการจัดลำดับการประมวลผลเพื่อทำหน้าที่ประสานงานกับกระบวนการต่างๆ ถ้าเราใช้วิธีการแก้ปัญหา consumer-producer problem โดยใช้บัฟเฟอร์ทั้งหมด เราสามารถทำได้โดยการใช้ integer count เพื่อจัดเก็บจำนวน track ทั้งหมดของบัฟเฟอร์ที่เต็ม โดยกำหนดค่าเริ่มต้นเป็น 0 และจะเพิ่มค่าขึ้นโดย producer เมื่อมีบัฟเฟอร์ว่างใหม่เข้ามา และจะลดค่าลงโดย consumer หลังจากใช้บัฟเฟอร์

Producer while (true) /* produce an item and put in nextProduced while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; }

Consumer while (1) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed }

สภาวะการแย่งชิง (race condition) ผลลัพธ์ที่ได้จะขึ้นอยู่กับนโยบายการจัดลำดับ (scheduling policy) ที่ใช้ การแก้ปัญหานี้ต้องประกันว่า จะมีเพียงกระบวนการเดียวเท่านั้น ณ ขณะใดขณะหนึ่งที่สามารถเปลี่ยนแปลงค่าตัวแปร counter ได้ ซึ่งจำเป็นต้องอาศัยการประสานเวลากระบวนการ (synchronized) เข้ามาช่วย

Race Condition count อาจเป็น 4 หรือ 6 ก็ได้ แต่ค่าที่ถูกต้องคือ 5 count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with “count = 5” initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} count อาจเป็น 4 หรือ 6 ก็ได้ แต่ค่าที่ถูกต้องคือ 5

ส่วนวิกฤติ Critical Section ถ้าในระบบหนึ่งประกอบด้วยกระบวนการหรือเธรดจำนวน n {T0, T1, …, Tn-1} ในการควบคุมการเข้าถึงทรัพยากรที่สามารถใช้ร่วมกันได้โดยกระบวนการหรือเธรดทั้งหมดนั้น สามารถทำได้โดยกำหนดให้แต่ละเธรดจะมีส่วนของรหัสที่เรียกว่า ส่วนวิกฤติ (critical section) ที่เธรดใช้ในการเปลี่ยนค่าของตัวแปรร่วม, การแก้ไขตาราง, เขียนแฟ้ม และอื่นๆ คุณลักษณะสำคัญของระบบนี้ก็คือ เมื่อมีเธรดหนึ่งกำลังกระทำการอยู่ในส่วนวิกฤติ จะต้องไม่มีเธรดใดๆ ที่ได้รับอนุญาตให้เข้าใช้ส่วนวิกฤตินี้ได้

การแก้ปัญหาส่วนวิกฤติ 1. การไม่เกิดร่วม (mutual exclusion) ถ้ามีเธรด Ti กำลังเข้ากระทำการบริเวณส่วนวิกฤติอยู่ จะต้องไม่มีเธรดอื่นใดสามารถเข้าใช้ส่วนวิกฤตินี้ได้ 2. ความก้าวหน้า (Progress) ถ้าไม่มีเธรดใดเข้ากระทำการอยู่ในส่วนวิกฤติ และมีเธรดใดๆ รอเข้าใช้ส่วนวิกฤติ เธรดเหล่านั้นจะต้องได้รับอนุญาตให้เข้าใช้ส่วนวิกฤติได้ทันทีโดยไม่ต้องรอเวลาใดๆ 3. การรอที่มีขอบเขต (Bounded waiting) เมื่อเธรดใดๆ ทำการร้องขอส่วนวิกฤติ การร้องขอนั้นจะต้องได้รับการตอบสนองอย่างรวดเร็วที่สุดเท่าที่จะเป็นไปได้นับตั้งแต่มีการร้องขอ โดยไม่เกิดภาวะรอคอยอย่างไม่มีขอบเขตสิ้นสุด ทั้งนี้ เพื่อป้องกันภาวะงูกินหาง (starvation)

Initial Attempts to Solve Problem Only 2 processes, P0 and P1 General structure of process Pi (other process Pj) do { entry section critical section exit section reminder section } while (1); กระบวนการทั้งหมดสามารถใช้ตัวแปรร่วมกันในการประสานการทำงานกัน อัลกอริธึมที่ใช้พิสูจน์แบบจำลองนี้มี 3 แบบ

Algorithm 1 Shared variables: int turn; initially turn = 0 turn - i  Pi can enter its critical section Process Pi do { while (turn != i) ; critical section turn = j; reminder section } while (1); อัลกอริธึมนี้รองรับการไม่เกิดร่วม (Mutual Exclusion) แต่ไม่รองรับความก้าวหน้า (Progress)

Algorithm 2 Shared variables boolean flag[2]; initially flag [0] = flag [1] = false. flag [i] = true  Pi ready to enter its critical section Process Pi do { flag[i] := true; while (flag[j]) ; critical section flag [i] = false; remainder section } while (1); อัลกอริธึมนี้ รองรับการไม่เกิดร่วม (Mutual Exclusion) แต่ไม่รองรับความก้าวหน้า (Progress)

Algorithm 3 Combined shared variables of algorithms 1 and 2. Process Pi do { flag [i]:= true; turn = j; while (flag [j] and turn = j) ; critical section flag [i] = false; remainder section } while (1); อัลกอริธึมนี้ รองรับเงื่อนไขได้ทั้ง 3 ข้อ และสามารถแก้ปัญหาส่วนวิกฤติสำหรับ 2 กระบวนการได้

ฮาร์ดแวร์ประสานเวลา Synchronization Hardware บนระบบโพรเซสเซอร์เดียวสามารถระงับการใช้ interrupts สามารถรับประกันได้ว่าลำดับของชุดคำสั่งจะถูกกระทำการโดยปราศจาการบังคับให้ออกจากเวลาซีพียู บนมัลติโพรเซสเซอร์ ไม่สามารถใช้งานได้ การห้ามขัดจังหวะบนโปรเซสเซอร์หลายตัวนั้นใช้เวลานานมากในการส่งข่าวสารไปยังโปรเซสเซอร์ทุกตัว การส่งข่าวสารจะก่อให้เกิดการหน่วงเวลาไปยังส่วนวิกฤติของทุกโปรเซสเซอร์ซึ่งส่งผลให้ประสิทธิภาพของระบบลดลง ยังส่งผลกระทบต่อนาฬิกาของระบบอีกด้วยถ้านาฬิกาบันทึกเวลาที่ถูกเปลี่ยนค่าโดยการขัดจังหวะ

ฮาร์ดแวร์ประสานเวลา Synchronization Hardware เครื่องในหลายระบบจึงจัดเตรียมชุดคำสั่งระดับฮาร์ดแวร์ที่ใช้สำหรับทดสอบและเปลี่ยนค่าของคำ หรือสำหรับสลับค่าระหว่างคำ 2 คำแบบภาวะครบหน่วย (atomic instruction) Atomic = non-interruptable ชุดคำสั่งฮาร์ดแวร์ประสานเวลาที่จัดเตรียมไว้เพื่อแก้ปัญหานี้ประกอบด้วย Test-and-Set Instruction Swap Instruction

Test-and-Set Instruction Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: }

Solution using TestAndSet Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) ; /* do nothing // critical section lock = FALSE; // remainder section } while ( TRUE);

Swap Instruction Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: }

Solution using Swap Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key. Solution: do { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section lock = FALSE; // remainder section } while ( TRUE);

เซมาฟอร์ Semaphore เป็นเครื่องมือประสานเวลาที่ไม่ต้องการเวลารอคอย เซมาฟอร์ S เป็นตัวแปรจำนวนเต็ม (integer) ช่วยลดความซับซ้อน สามารถเข้าถึงได้ผ่านคำสั่งปฏิบัติการมาตรฐาน 2 คำสั่งปฏิบัติการแบบภาวะครบหน่วย (atomic operation) ได้แก่ wait และ signal คำสั่งปฏิบัติการแบบภาวะครบหน่วย (atomic operation) เมื่อกระบวนการหนึ่งกำลังแก้ไขค่าเซมาฟอร์ จะต้องไม่มีกระบวนการอื่นที่สามารถแก้ไขค่าเซมาฟอร์เดียวกันได้ในเวลาเดียวกัน กรณีของ wait(S) การทดสอบค่าจำนวนเต็มของ S (S  0) และการแก้ไขค่า (S--) จะต้องกระทำการโดยปราศจากขัดจังหวะ

เซมาฟอร์ (2) Semaphore Originally called P() and V() wait (S) { S: wait() and signal() Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++;

Semaphore as General Synchronization Tool แบ่งตัวแปรเซมาฟอร์ออกเป็น 2 ชนิด ได้แก่ เซมาฟอร์นับ (Counting semaphore) มีค่าที่เป็นไปได้ไม่จำกัด เซมาฟอร์ไบนารี (Binary semaphore) มีค่าที่เป็นได้คือ 0 และ 1 ง่ายต่อการใช้งาน บางทีเรียกว่า mutex locks โดยค่าของเซมาฟอร์นับไม่จำกัดขอบเขต ส่วนค่าที่เป็นไปได้ของเซมาฟอร์ไบนารีได้แก่ 0 กับ 1 เพื่อให้ใช้งานได้ง่าย สามารถใช้ counting semaphore S เป็นไบนารีเซมาฟอร์ Provides mutual exclusion Semaphore S; // initialized to 1 wait (S); Critical Section signal (S);

Semaphore Implementation เราสามารถใช้เซมาฟอร์ไบนารีควบคุมการเข้าถึงส่วนวิกฤติสำหรับกระบวนการหรือเธรดใดๆ โดยจะมีเพียงเธรดเดียวเท่านั้นที่สามารถเข้าสู่ส่วนวิกฤติได้ ณ ขณะใดขณะหนึ่ง ส่วนเซมาฟอร์นับสามารถใช้ควบคุมการเข้าถึงทรัพยากรที่สอดคล้องกันเพียงค่าจำนวนจำกัดเท่านั้น โดยเซมาฟอร์จะกำหนดค่าของจำนวนทรัพยากรที่สามารถใช้งานได้ แต่ละเธรดที่ต้องการใช้ทรัพยากรดังกล่าวก็จะเรียกคำสั่งปฏิบัติการ P บนเซมาฟอร์ (เพื่อลดค่าจำนวนนับ) เมื่อเธรดนั้นปลดปล่อยทรัพยากรก็จะเรียกคำสั่งปฏิบัติการ V (เพิ่มค่าจำนวนนับ) เมื่อค่าจำนวนนับของเซมาฟอร์ไปจนถึงค่า 0 ก็แสดงว่าทรัพยากรทั้งหมดกำลังถูกใช้งาน ในระหว่างนี้ ถ้าเธรดใดร้องขอทรัพยากรก็จะต้องถูกหยุดให้รอจนกระทั่งค่าตัวนับมากกว่า 0

Semaphore Implementation with no Busy waiting เซมาฟอร์แต่ละตัวจะมีการเชื่อมโยงไปยังแถวคอย (waiting queue) แต่ละรายการในแถวคอยจะมีเพียง 2 รายการ value (of type integer) pointer (ตัวชี้ไปยังเรคคอร์ดถัดไปในรายการ) Two operations: block –หยุดกระบวนการที่ร้องขอ wakeup(P) กลับมากระทำการกระบวนการ P ที่ถูกหยุดไว้ต่อ (โดยเปลี่ยนสถานะจากรอเป็นพร้อม)

Semaphore Implementation with no Busy waiting (Cont.) Implementation of wait: wait (S){ value--; if (value < 0) { add this process to waiting queue block(); } } Implementation of signal: Signal (S){ value++; if (value <= 0) { remove a process P from the waiting queue wakeup(P); }

ภาวะติดตายและงูกินหาง Deadlock and Starvation on Semaphore Let S and Q be two semaphores initialized to 1 P0 P1 wait (S); wait (Q); wait (Q); wait (S); . . signal (S); signal (Q); signal (Q); signal (S); ภาวะงูกินหาง (starvation) หรือ การหยุดรออย่างไม่มีกำหนด (indefinite blocking) เป็นสถานการณ์ที่มีหลายกระบวนการกำลังรอคอยอย่างไม่มีกำหนดอยู่ภายในเซมาฟอร์ เพราะมีกระบวนการหนึ่งกำลังใช้เซมาฟอร์อยู่

ปัญหาพื้นฐานของการประสานเวลา Classical Problems of Synchronization ปัญหาพื้นฐานที่ใช้ทดสอบวิธีการแก้ปัญหาการประสานเวลา Bounded-Buffer problem (Producer/Consumer problem) Readers and Writers problem Dining-Philosophers problem

Bounded-Buffer Problem บางทีเรียกว่าปัญหาผู้ผลิต-ผู้บริโภค (Producer/Consumer problem) เป็นปัญหาที่นิยมใช้ในการทดสอบประสิทธิภาพของเทคนิคการประสานเวลา มีผู้ผลิตหนึ่งคนหรือมากกว่าทำการผลิตข้อมูลบางชนิด (ระเบียน, อักขระ) และใส่ลงในบัฟเฟอร์ และมีผู้บริโภคเพียงคนเดียวเท่านั้นที่สามารถหยิบข้อมูลนั้นออกจากบัฟเฟอร์ในขณะใดขณะหนึ่ง ระบบจะต้องกำหนดเงื่อนไขเพื่อป้องกันไม่ให้เกิดการทับซ้อนกันในการปฏิบัติการบนบัฟเฟอร์นั้น หมายความว่า ณ ขณะใดขณะหนึ่ง จะมี (ผู้ผลิตหรือผู้บริโภค) เพียงคนเดียวเท่านั้นที่สามารถเข้าถึงบัฟเฟอร์ได้

Bounded-Buffer Problem (Cont.) N buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Semaphore empty initialized to the value N.

Bounded Buffer Problem (Cont.) The structure of the producer process do { // produce an item wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (true);

Bounded Buffer Problem (Cont.) The structure of the consumer process do { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume the removed item } while (true);

Readers-Writers Problem ปัญหาผู้อ่าน-ผู้เขียนถือเป็นปัญหาที่ใช้ในการทดสอบกลไกการแก้ปัญหาเกี่ยวกับการควบคุมภาวะพร้อมกัน ชุดข้อมูลที่ใช้ร่วมกันระหว่างกระบวนการทั้งหมดในเวลาเดียวกันนั้น ผู้อ่าน สามารถอ่านข้อมูลได้อย่างเดียว, ไม่มีการ update ผู้เขียน สามารถทำได้ทั้งอ่านและเขียน ปัญหานี้คือ มีพื้นที่ข้อมูลซึ่งใช้ร่วมกันได้ระหว่างกระบวนการทั้งหมด มีกระบวนการจำนวนมากที่ต้องการอ่าน (readers) พื้นที่ดังกล่าวเพียงอย่างเดียว และมีกระบวนการที่ต้องการเขียน (writers) บนพื้นที่ดังกล่าวเพียงกระบวนการเดียวในเวลาเดียวกัน

Readers-Writers Problem (Cont.) การจัดการจะต้องเข้ากันได้กับเงื่อนไขดังต่อไปนี้ 1. ผู้อ่านสามารถอ่านแฟ้มได้พร้อมกันหลายคน 2. มีผู้เขียนเพียงคนเดียวเท่านั้นที่สามารถเขียนแฟ้มได้ ณ เวลาใดเวลาหนึ่ง 3. ถ้ามีผู้เขียนรอที่จะเขียนแฟ้ม จะต้องไม่มีผู้อ่านคนใดสามารถอ่านแฟ้มนั้นได้ จากข้อกำหนดข้างต้นอาจนำไปสู่ปัญหาภาวะงูกินหาง กรณีแรก ผู้เขียนอาจต้องเป็นฝ่ายรออย่างไม่รู้จบ กรณีหลัง ผู้อ่านอาจต้องเป็นฝ่ายรออย่างไม่รู้จบ Shared Data Data set Semaphore mutex initialized to 1. Semaphore wrt initialized to 1. Integer readcount initialized to 0.

Readers-Writers Problem (Cont.) The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (true)

Readers-Writers Problem (Cont.) The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readercount == 1) wait (wrt) ; signal (mutex) // reading is performed readcount - - ; if redacount == 0) signal (wrt) ; signal (mutex) ; } while (true)

Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1

Dining-Philosophers Problem (Cont.) นักปรัชญาจำนวน 5 คนนั่งบนเก้าอี้ล้อมรอบโต๊ะกลม มีถ้วยใส่ข้าวจำนวน 5 ถ้วยวางไว้บนโต๊ะ มีตะเกียบอยู่จำนวน 5 อันวางไว้ด้านซ้ายมือและด้านขวามือของเขาข้างละหนึ่งอัน เมื่อเวลาหิวก็จะพยายามหยิบตะเกียบจากด้านซ้ายและขวามือขึ้นมาข้างละอันจึงจะสามารถบริโภคอาหารได้ และในระหว่างบริโภคก็จะไม่วางตะเกียบตลอดจนกระทั่งอิ่มจึงค่อยวางตะเกียบลง ถ้ามีนักปรัชญาที่นั่งอยู่ด้านข้างหิวและพยายามหยิบตะเกียบขึ้นมา แต่ถ้าตะเกียบข้างใดข้างหนึ่งหรือทั้งสองข้างไม่ว่างก็จะต้องรอ

Dining-Philosophers Problem (Cont.) The structure of Philosopher i: Do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (true) ;

Problems with Semaphores สะท้อนถึงปัญหาสำคัญเกี่ยวกับการควบคุมภาวะพร้อมกันบนสภาพแวดล้อมของระบบปฏิบัติการ เช่น การจัดสรรทรัพยากรจำนวนมากให้แก่กระบวนการจำนวนมากที่อาจตกอยู่ภายใต้สถานการณ์ของภาวะติดตายและงูกินหางที่มีการรออย่างไม่รู้จบ การแก้ปัญหาอย่างง่ายวิธีหนึ่ง คือ การแทนตะเกียบแต่ละอันด้วยเซมาฟอร์ นักปรัชญาคนหนึ่งพยายามหยิบตะเกียบโดยการใช้คำสั่งปฏิบัติการ P บนเซมาฟอร์ และวางตะเกียบโดยการใช้คำสั่งปฏิบัติการ V บนเซมาฟอร์ที่เหมาะสม

Problems with Semaphores (Cont.) Correct use of semaphore operations: signal (mutex) …. wait (mutex) wait (mutex) … wait (mutex) Omitting of wait (mutex) or signal (mutex) (or both)

Problems with Semaphores (Cont.) ในการป้องกันภาวะติดตายจากสถานการณ์นี้ สามารถกำหนดเงื่อนไข ดังต่อไปนี้ อนุญาตให้นักปรัชญาเพียง 4 คนนั่งพร้อมๆ กันอยู่ที่โต๊ะกลมได้ อนุญาตให้นักปรัชญาหยิบตะเกียบได้ก็ต่อเมื่อตะเกียบด้านซ้ายและขวาวางไว้อยู่ (เขาจะต้องหยิบตะเกียบทั้งคู่ในส่วนวิกฤติ) ใช้วิธีแก้ปัญหาแบบอสมมาตร ตัวอย่างเช่น นักปรัชญาเลขคี่จะหยิบตะเกียบด้านซ้ายก่อน ถ้าได้จึงหยิบด้านขวา ในขณะที่นักปรัชญาเลขคู่ให้เริ่มหยิบตะเกียบด้านขวาก่อนแลเวจึงหยิบตะเกียบด้านซ้าย วิธีการนี้จะรับประกันว่าไม่มีการแย่งชิงที่เป็นสาเหตุให้นักปรัชญาคนหนึ่งเข้าสู่ภาวะติดตาย แต่วิธีนี้ไม่ได้ป้องกันภาวะการรออย่างไม่รู้จบ

ตัวเฝ้าสังเกต Monitors ตัวเฝ้าสังเกตเป็นซอฟต์แวร์มอดูลที่ประกอบด้วยหนึ่งหรือมากกว่ากระบวนงาน (procedure) ทำการกำหนดค่าการจัดลำดับ และตัวแปรข้อมูลเฉพาะที่ เป็นกลไกที่ใช้งานง่ายกว่าเซมาฟอร์ และมีประสิทธิภาพที่ใช้สำหรับประสานเวลากระบวนการ คุณลักษณะสำคัญของตัวเฝ้าสังเกตประกอบด้วย ตัวแปรข้อมูลเฉพาะที่จะสามารถเข้าถึงได้โดยกระบวนงานเฉพาะที่ของตัวเฝ้าสังเกตเท่านั้น และไม่สามารถเข้าถึงได้โดยกระบวนงานอื่นๆ จากภายนอก กระบวนการเข้าสู่ตัวเฝ้าสังเกตได้โดยการเรียกกระบวนงานเฉพาะที่บางอย่างของตัวเฝ้าสังเกต มีเพียงกระบวนการเดียวเท่านั้นที่ถูกกระทำการได้โดยตัวเฝ้าสังเกตในขณะใดขณะหนึ่ง ถ้ามีกระบวนการอื่นต้องการใช้ตัวเฝ้าสังเกตก็จะต้องหยุดรอจนกระทั่งตัวเฝ้าสังเกตว่างลง ณ เวลาใดเวลาหนึ่ง จะมีเพียงกระบวนการเดียวเท่านั้นที่ active อยู่ภายในตัวเฝ้าสังเกต

ตัวเฝ้าสังเกต Monitors monitor monitor-name { // shared variable declarations procedure P1 (…) { …. } … procedure Pn (…) {……} Initialization code ( ….) { … } }

Schematic view of a Monitor

Condition Variables condition x, y; Two operations on a condition variable: x.wait () – a process that invokes the operation is suspended. x.signal () – resumes one of processes (if any) tha invoked x.wait ()

Monitor with Condition Variables

Solution to Dining Philosophers สำหรับการแก้ปัญหานักปรัชญาบริโภคนั้น กำหนดให้การจ่ายตะเกียบถูกควบคุมโดยตัวเฝ้าสังเกต กำหนดให้นักปรัชญาแต่ละคนก่อนจะเริ่มต้นบริโภคจะต้องเรียกคำสั่ง pickUp() จนกระทั่งสำเร็จจึงจะเริ่มบริโภคได้ หลังจากบริโภคเสร็จต้องเรียกคำสั่ง putDown() และเริ่มคิดต่อไป ดังนั้น นักปรัชญา i จะต้องเรียกใช้คำสั่ง pickUp() และ putDown() ตามลำดับ

Solution to Dining Philosophers (cont.) monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5);

Solution to Dining Philosophers (cont.) void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i].signal () ; } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING;

Synchronization Examples Solaris Windows XP Linux Pthreads

Solaris Synchronization การใช้ lock หลายแบบ เพื่อสนับสนุนระบบ multitasking และ multithreading (รวมทั้ง real-time threads) และ multiprocessing ใช้ adaptive mutexes เพื่อความสะดวกในการป้องกันข้อมูลจากรหัสเซ้กเมนท์สั้นๆ short code segments ใช้ lock แบบ condition variables and readers-writers เมื่อเซ็กชันของรหัสที่ยาวกว่าต้องการใช้ข้อมูล ใช้ turnstiles ในการจัดลำดับรายการเธรดที่กำลังรอคอย ที่ต้องการ adaptive mutex or reader-writer lock

Windows XP Synchronization ใช้ interrupt เพื่อป้องกันการเข้าถึงทรัพยากรส่วนกลางบนระบบโพรเซสเซอร์เดียว (uniprocessor systems) ใช้ spinlocks บน multiprocessor systems มีการเตรียม dispatcher objects ที่ทำหน้าที่เป็น mutexes และ semaphores Dispatcher objects อาจจัดหาเหตุการณ์บางอย่าง (events) เหตุการณ์ทำหน้าที่เช่นเดียวกันตัวแปรแบบมีเงื่อนไข (condition variable)

Linux Synchronization ระงับการใช้ interrupts โดยใช้ส่วนวิกฤติขนาดเล็ก (short critical sections) แทน Linux provides: semaphores spin locks

Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables Non-portable extensions include: read-write locks spin locks

End of Process Synchronization