ปัญหาระหว่างผู้อ่านและผู้เขียน

ในวิทยาการคอมพิวเตอร์ปัญหาผู้อ่าน-ผู้เขียนเป็นตัวอย่างของปัญหาการคำนวณทั่วไปในการทำงานพร้อมกัน [ ^{1 ] มี}ปัญหาอย่างน้อยสามรูปแบบ ซึ่งเกี่ยวข้องกับสถานการณ์ที่เธรดการทำงานพร้อมกันจำนวนมากพยายามเข้าถึงทรัพยากรที่ใช้ร่วมกัน เดียวกัน ในเวลาเดียวกัน

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

ปัญหาพื้นฐานระหว่างผู้อ่านและผู้เขียนได้รับการกำหนดและแก้ไขครั้งแรกโดย Courtois et al. ^{[ 2 ] [ 3 ]}

สมมติว่าเรามีพื้นที่หน่วยความจำที่ใช้ร่วมกัน (ส่วนวิกฤต) พร้อมข้อจำกัดพื้นฐานที่อธิบายไว้ข้างต้น เป็นไปได้ที่จะปกป้องข้อมูลที่ใช้ร่วมกันด้วยmutex การกีดกันร่วมกัน ซึ่งในกรณีนี้ _จะไม่มีเธรดสองเธรดใดสามารถเข้าถึงข้อมูลได้ในเวลาเดียวกัน อย่างไรก็ตาม วิธีแก้ปัญหานี้ไม่เหมาะสมที่สุด เพราะเป็นไปได้ที่ผู้อ่านR1อาจมีล็อกอยู่ และจากนั้นผู้อ่านอีกคนหนึ่ง_R2ร้องขอการเข้าถึง มันคงไม่ฉลาดนักที่R2จะรอจนกว่า_R1จะอ่านเสร็จก่อนที่จะเริ่มการอ่านของตนเอง แทนที่จะเป็นเช่นนั้น_{R2 ควร}ได้รับอนุญาตให้อ่านทรัพยากรไปพร้อมกับ_R1เพราะการอ่านไม่ได้แก้ไขข้อมูล ดังนั้นการอ่านพร้อมกันจึงปลอดภัย นี่คือแรงจูงใจสำหรับ ปัญหา ผู้อ่าน-ผู้เขียนข้อแรกซึ่งมีการเพิ่มข้อจำกัดว่าไม่ควรให้ผู้อ่านคนใดรอหากส่วนแบ่งนั้นเปิดให้สำหรับการอ่านอยู่แล้ว เรียกอีกอย่างว่าปัญหาความชอบของผู้อ่าน (readers-preference ) พร้อมวิธีแก้ปัญหา:

ทรัพยากรเซมาฟอร์= 1 ;สัญญาณไฟrmutex = 1 ;จำนวนการอ่าน= 0 ;/* resource.P() เทียบเท่ากับ wait(resource) resource.V() เทียบเท่ากับ signal(resource) rmutex.P() เทียบเท่ากับ wait(rmutex) rmutex.V() เทียบเท่ากับ signal(rmutex)*/นักเขียน() {resource.P ( ); //ล็อกไฟล์ที่แชร์สำหรับผู้เขียน< ส่วนสำคัญ>// การเขียนเสร็จสิ้นแล้วresource.V (); //ปล่อยไฟล์ที่แชร์เพื่อให้ผู้ อ่าน คนอื่นใช้งาน ได้ผู้เขียนจะได้รับอนุญาตหากไม่มีผู้อ่านร้องขอ}ผู้อ่าน() {< ส่วนการลงทะเบียน>rmutex.P ( ); // ตรวจสอบให้แน่ใจว่าไม่มีผู้อ่านคนอื่นสามารถเรียกใช้ส่วน <Entry> ได้ในขณะที่คุณอยู่ในส่วนนั้นreadcount ++ ; //ระบุว่าคุณเป็นผู้อ่านที่พยายามเข้าสู่ส่วนวิกฤตถ้า( readcount == 1 ) //ตรวจสอบว่าคุณเป็นผู้อ่านคนแรกที่พยายามเข้าสู่ CS หรือไม่resource.P ( ); // หากคุณเป็นผู้อ่านคนแรก ให้ล็อกทรัพยากรจากผู้เขียน ทรัพยากรจะยังคงถูกสงวนไว้สำหรับผู้อ่านคนถัดไปrmutex.V ( ); // ปล่อย< ส่วนสำคัญ>// อ่านหนังสือ< ส่วนทางออก>rmutex.P ( ); // ตรวจสอบให้แน่ใจว่าไม่มีผู้อ่านคนอื่นสามารถเรียกใช้ส่วน <Exit> ได้ในขณะที่คุณอยู่ในส่วนนั้นจำนวนการอ่าน-- ; //ระบุว่าคุณไม่ต้องการทรัพยากรที่ใช้ร่วมกันอีกต่อไป จำนวนผู้อ่านลดลงหนึ่งคนถ้า( readcount == 0 ) //ตรวจสอบว่าคุณเป็นผู้อ่านคนสุดท้าย (หรือคนเดียว) ที่กำลังอ่านไฟล์ที่แชร์อยู่หรือไม่resource.V ( ); // หากคุณเป็นผู้อ่านคนสุดท้าย คุณสามารถปลดล็อกทรัพยากรได้ ซึ่งจะทำให้ทรัพยากรนี้พร้อมใช้งานสำหรับนักเขียนrmutex.V ( ); // ปล่อย}

ในวิธีแก้ปัญหาผู้อ่าน/ผู้เขียนนี้ ผู้อ่านคนแรกจะต้องล็อกทรัพยากร (ไฟล์ที่ใช้ร่วมกัน) หากมีให้ใช้งาน เมื่อไฟล์ถูกล็อกจากผู้เขียนแล้ว ผู้อ่านคนต่อๆ ไปจำนวนมากสามารถใช้ไฟล์นั้นได้โดยไม่ต้องล็อกอีกครั้ง

ก่อนเข้าสู่ส่วนวิกฤต (critical section ) ผู้อ่านใหม่ทุกคนต้องผ่านส่วนทางเข้า (entry section) ก่อน อย่างไรก็ตาม จะมีผู้อ่านอยู่ในส่วนทางเข้าได้เพียงครั้งละหนึ่งคนเท่านั้น เพื่อหลีกเลี่ยงสภาวะการแข่งขัน (race condition) บนผู้อ่าน (ในบริบทนี้ สภาวะการแข่งขันคือสภาวะที่เธรดสองเธรดขึ้นไปตื่นขึ้นพร้อมกันและพยายามเข้าสู่ส่วนวิกฤต หากไม่มีข้อจำกัดเพิ่มเติม พฤติกรรมจะไม่สามารถคาดเดาได้ เช่น ผู้อ่านสองคนเพิ่มค่าreadcountพร้อมกัน และทั้งคู่พยายามล็อกทรัพยากร ทำให้ผู้อ่านคนหนึ่งถูกบล็อก) เพื่อให้บรรลุเป้าหมายนี้ ผู้อ่านทุกคนที่เข้าสู่ <ส่วนทางเข้า> จะล็อก <ส่วนทางเข้า> สำหรับตัวเองจนกว่าจะเสร็จสิ้น ในขั้นตอนนี้ ผู้อ่านจะไม่ล็อกทรัพยากร พวกเขาจะล็อกเฉพาะส่วนทางเข้าเพื่อไม่ให้ผู้อ่านคนอื่นเข้ามาได้ในขณะที่พวกเขากำลังอยู่ในนั้น เมื่อผู้อ่านดำเนินการในส่วนทางเข้าเสร็จแล้ว พวกเขาจะปลดล็อกโดยการส่งสัญญาณไปยัง mutex การส่งสัญญาณนั้นเทียบเท่ากับ mutex.V() ในโค้ดข้างต้น หลักการเดียวกันนี้ใช้ได้กับ <ส่วนทางออก> ด้วย จะมีผู้อ่านได้เพียงคนเดียวในบริเวณทางออกในแต่ละครั้ง ดังนั้นผู้อ่านทุกคนจะต้องจองและล็อกบริเวณทางออกสำหรับตนเองก่อนใช้งาน

เมื่อผู้อ่านคนแรกเข้ามาในส่วนป้อนข้อมูล ระบบจะล็อกทรัพยากรนั้น การทำเช่นนี้จะป้องกันไม่ให้ผู้เขียนเข้าถึงได้ ผู้อ่านคนถัดไปสามารถใช้ทรัพยากรที่ถูกล็อก (จากผู้เขียน) ได้เลย ผู้อ่านที่อ่านจบเป็นคนสุดท้าย (ระบุโดยreadcountตัวแปร) จะต้องปลดล็อกทรัพยากรนั้น เพื่อให้ผู้เขียนสามารถเข้าถึงได้

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

วิธีแก้ปัญหาแรกมีข้อเสียคืออาจทำให้เกิดภาวะขาดแคลนทรัพยากร ซึ่งหมายความ _ว่าจะไม่สามารถเขียนลงไฟล์ได้หากไฟล์นั้นถูกอ่านอยู่ตลอดเวลา หากผู้อ่านR1มีล็อกอยู่ขณะที่ผู้เขียนWกำลังรอรับล็อก และจากนั้นผู้อ่านR2ร้องขอการเข้าถึง อาจถือว่า "ไม่ยุติธรรม" ที่R2จะเข้ามาแทรกแซงทันทีโดยแซงหน้า W นี่คือแรงจูงใจสำหรับปัญหาผู้อ่าน-ผู้เขียนแบบที่สอง ซึ่งมีการเพิ่มข้อจำกัดว่าเมื่อเพิ่มผู้เขียนลงในคิวแล้ว จะต้องไม่ปล่อยให้ผู้เขียนรอเกินความจำเป็นอย่างยิ่ง นี่เรียกว่า การให้_ความสำคัญ_กับผู้เขียน ( writers - preference )

วิธีแก้ปัญหาสถานการณ์ความชอบของนักเขียนคือ: ^{[ 2 ]}

จำนวนการอ่านและการเขียน; //(ค่าเริ่มต้น = 0)เซมาฟอร์readcount_mutex , writecount_mutex , readTry , reader_mutex , writer_mutex ; //(ค่าเริ่มต้น = 1)//ผู้อ่านผู้อ่าน() {< ส่วนการลงทะเบียน>readTry.P ( ); //ป้องกันไม่ให้ผู้ อ่านหลายคนรอผู้เขียนreader_mutex.P ( ); //ล็อกส่วนทางเข้าหรือรอผู้เขียนตามความจำเป็นreadcount_mutex.P ( ); //ป้องกันการแข่งขัน ที่ล็อกตัวเขียนและตัวนับreadcount ++ ; //เพิ่มจำนวนผู้อ่านถ้า( readcount == 1 ) //ตรวจสอบว่าคุณเป็นผู้อ่านคนแรกหรือไม่writer_mutex.P ( ) ; // หากคุณเป็นผู้อ่านคนแรก ป้องกันการเข้าถึงการเขียนreadcount_mutex . V ();reader_mutex.V ( ); //ปล่อยส่วนทางเข้าและอนุญาต ให้ผู้เขียนใช้ได้หากจำเป็นreadTry.V (); //ระบุว่าคุณไม่ได้พยายามเข้าถึงทรัพยากรอีกต่อไปแล้ว< ส่วนสำคัญ>//การอ่านข้อมูลกำลังดำเนินการอยู่< ส่วนทางออก>readcount_mutex.P ( ); //หลีกเลี่ยงสภาวะการแข่งขันในการอ่านข้อมูลร่วมกับผู้อ่านรายอื่นอ่านซ้ำ-- ; //ระบุว่าคุณกำลังจะออกถ้า( readcount == 0 ) //ตรวจสอบว่าคุณเป็นผู้อ่านคนสุดท้ายที่กำลังจะออกจากระบบหรือไม่writer_mutex.V ( ); // ถ้า เป็นกรณีสุดท้าย คุณต้องปล่อยทรัพยากรที่ถูกล็อกreadcount_mutex.V ( ); //ปล่อยส่วนทางออกสำหรับผู้อ่านรายอื่น}//นักเขียนนักเขียน() {< ส่วนข้อมูลเริ่มต้น> //ส่วนข้อมูลเริ่มต้นจากตรงนี้writecount_mutex.P ( ); //หลีกเลี่ยงสภาวะการแข่งขันในการเขียนข้อมูลร่วมกับผู้เขียนรายอื่นwritecount ++ ; //รายงานตัวเองว่าเป็นผู้เขียนที่กำลังป้อนข้อมูลถ้า( จำนวนการเขียน== 1 ) //ตรวจสอบว่าคุณเป็นผู้เขียนคนแรกหรือไม่reader_mutex.P ( ); // ถ้าคุณเป็นคนแรก คุณต้องล็อกไม่ ให้ผู้อ่านเข้าถึง ป้องกันไม่ให้พวกเขาพยายามเข้าสู่ CSwritecount_mutex.V ( ); // ปล่อยส่วนทางเข้า< ส่วนสำคัญ> //ส่วนสำคัญเริ่มต้นจากตรงนี้writer_mutex.P ( ); //สงวนทรัพยากรไว้สำหรับตัวคุณเอง - ป้องกันไม่ให้ผู้เขียนคนอื่นแก้ไขทรัพยากรที่ใช้ร่วมกันพร้อมกัน//การเขียนกำลังดำเนินการอยู่writer_mutex.V ( ); // ปล่อยไฟล์< ส่วนทางออก> //ส่วนทางออกเริ่มต้นจากตรงนี้writecount_mutex.P ( ); // สำรองส่วนทางออกwritecount -- ; //ระบุว่าคุณกำลังจะออกจากโปรแกรมถ้า( จำนวนการเขียน== 0 ) //ตรวจสอบว่าคุณเป็นผู้เขียนคนสุดท้ายหรือไม่reader_mutex.V ( ); // ถ้าคุณเป็นผู้เขียนคนสุดท้าย คุณต้องปลดล็อกผู้อ่าน เพื่อให้พวกเขาสามารถลองเข้า CS เพื่ออ่านได้writecount_mutex.V ( ); // ปล่อยส่วนทางออก}

ในวิธีแก้ปัญหานี้ จะให้ความสำคัญกับผู้เขียนก่อน โดยการบังคับให้ผู้อ่านแต่ละคนล็อกและปลดreadTryล็อกเซมาฟอร์ด้วยตนเอง ดังนั้น จะมีผู้อ่านเพียงคนเดียวเท่านั้นที่สามารถแสดงว่ากำลังพยายามอ่านในเวลาใดเวลาหนึ่งได้โดยการพยายามขอรับreader_mutexเซมาฟอร์ ณ จุดนี้ หากมีผู้เขียนมากกว่าหนึ่งคนประกาศตัวแล้ว ผู้เขียนคนแรกจะขอรับreader_mutexเซมาฟอร์ไปก่อน ทำให้ผู้อ่านถูกบล็อก ผู้อ่านจะสามารถดำเนินการต่อได้ก็ต่อเมื่อไม่มีผู้เขียนคนอื่นแล้วเท่านั้น เนื่องจากreadcountมีการแก้ไขในหลายที่ การเข้าถึงจึงต้องถูกล็อกไว้readcount_mutexเบื้องหลัง

ผู้เขียนหลายคนสามารถประกาศตนเองได้โดยการเพิ่มค่าขึ้นเรื่อยๆwritecountอย่างไรก็ตาม มีเพียงผู้เขียนคนแรกเท่านั้นที่จะล็อกเซ มาฟอร์ reader_mutexเพื่อป้องกันไม่ให้ผู้อ่านดำเนินการต่อ ผู้เขียนคนต่อๆ ไปจะใช้ทรัพยากรตามลำดับโดยการรับเซมาฟอร์writer_mutexก่อนการดำเนินการเขียนและปล่อยเซมาฟอร์หลังจากนั้น ผู้เขียนคนสุดท้ายจะต้องปล่อยreader_mutexเซมาฟอร์ ซึ่งเป็นการเปิดประตูให้ผู้อ่านสามารถลองอ่านได้

โปรดทราบว่า หากไม่มีผู้เขียนข้อมูลเลย เซมาฟอร์ ` readTryand` reader_mutexจะซ้ำซ้อนกับ `set` readcount_mutexโดยทำหน้าที่เพียงป้องกันสภาวะการแข่งขัน (race condition) บนreadcountตัวแปรเท่านั้น ดังนั้นผู้อ่านหลายคนจึงสามารถประกาศตนเองและอ่านข้อมูลที่ใช้ร่วมกันได้พร้อมกัน

อันที่จริงแล้ว วิธีแก้ปัญหาที่เสนอโดยโจทย์ทั้งสองข้ออาจนำไปสู่ภาวะอดอยาก — ข้อแรกอาจทำให้ผู้เขียนในคิวอดอยาก และข้อที่สองอาจทำให้ผู้อ่านอดอยาก ดังนั้น จึง มีการเสนอ แนวคิดปัญหาที่สามเกี่ยวกับผู้อ่านและผู้เขียนขึ้นมา ซึ่งเพิ่มข้อจำกัดว่าไม่ควรอนุญาตให้เธรดใด ๆ อดอยาก กล่าว คือ การดำเนินการเพื่อขอการล็อกข้อมูลที่ใช้ร่วมกันจะสิ้นสุดลงภายในระยะเวลาที่จำกัดเสมอ วิธีแก้ปัญหาที่เป็นธรรมสำหรับทั้งผู้อ่านและผู้เขียนอาจเป็นดังนี้:

int readcount ; // กำหนดค่าเริ่มต้นเป็น 0; จำนวนผู้อ่านที่กำลังเข้าถึงทรัพยากรอยู่ในขณะนี้// เซมาฟอร์ทั้งหมดถูกกำหนดค่าเริ่มต้นเป็น 1ทรัพยากรเซมาฟอร์; // ควบคุมการเข้าถึง (อ่าน/เขียน) ทรัพยากร เซมาฟอร์แบบไบนารีsemaphore rmutex ; // สำหรับซิงค์การเปลี่ยนแปลงไปยังตัวแปรที่ใช้ร่วมกัน readcountเซมาฟอร์ เซอร์วิสคิว; // ความเป็นธรรม: รักษาลำดับของคำขอ (การส่งสัญญาณต้องเป็นแบบ FIFO)//ผู้อ่านผู้อ่าน() {< ส่วนการลงทะเบียน>serviceQueue.P ( ); // รอคิวเพื่อรับบริการrmutex.P ( ); // ขอสิทธิ์การเข้าถึง readcount แต่เพียงผู้เดียวreadcount ++ ; // อัปเดตจำนวนผู้อ่านที่ใช้งานอยู่ถ้า( readcount == 1 ) // ถ้าฉันเป็นผู้อ่านคนแรกresource.P (); // ขอสิทธิ์การ เข้าถึง ทรัพยากร สำหรับผู้อ่าน (ผู้เขียนถูกบล็อก)serviceQueue.V ( ); // ให้ดำเนินการกับรายการถัดไปในคิวrmutex.V ( ); // ปล่อยสิทธิ์การเข้าถึง readcount< ส่วนสำคัญ>//การอ่านข้อมูลกำลังดำเนินการอยู่< ส่วนทางออก>rmutex.P ( ); // ขอสิทธิ์การเข้าถึง readcount แต่เพียงผู้เดียวreadcount -- ; // อัปเดตจำนวนผู้อ่านที่ใช้งานอยู่ถ้า( readcount == 0 ) // ถ้าไม่มีผู้อ่านเหลืออยู่แล้วresource.V (); // ปล่อยการเข้าถึงทรัพยากรสำหรับทุกคนrmutex.V ( ); // ปล่อยสิทธิ์การเข้าถึง readcount}//นักเขียนนักเขียน() {< ส่วนการลงทะเบียน>serviceQueue.P ( ); // รอคิวเพื่อรับบริการresource.P (); // ร้องขอสิทธิ์การเข้าถึงทรัพยากรแต่เพียงผู้เดียวserviceQueue.V ( ); // ให้ดำเนินการกับรายการถัดไปในคิว< ส่วนสำคัญ>// การเขียนกำลังดำเนินการอยู่< ส่วนทางออก>resource.V (); // ปล่อยการเข้าถึงทรัพยากรสำหรับผู้อ่าน/ผู้เขียนรายถัดไป}

วิธีแก้ปัญหานี้จะสามารถตอบสนองเงื่อนไขที่ว่า "จะต้องไม่ปล่อยให้เธรดใด ๆ อดอยาก" ได้ก็ต่อเมื่อเซมาฟอร์รักษาลำดับการเข้าก่อนออกก่อน (FIFO) เมื่อบล็อกและปล่อยเธรดเท่านั้น มิเช่นนั้น ผู้เขียนที่ถูกบล็อกอาจยังคงถูกบล็อกอย่างไม่มีกำหนด โดยมีผู้เขียนคนอื่น ๆ ลดค่าเซมาฟอร์ลงก่อนที่ผู้เขียนคนนั้นจะถูกบล็อกได้

ปัญหาการอ่านเขียนที่ง่ายที่สุด ซึ่งใช้เซมาฟอร์เพียงสองตัว และไม่จำเป็นต้องใช้อาร์เรย์ของตัวอ่านเพื่ออ่านข้อมูลในบัฟเฟอร์

โปรดสังเกตว่าวิธีแก้ปัญหานี้จะง่ายกว่ากรณีทั่วไป เนื่องจากเทียบเท่ากับ ปัญหา บัฟเฟอร์ที่มีขอบเขต จำกัด ดังนั้นจึงอนุญาตให้ผู้อ่าน เพียง N คนเท่านั้นเข้าใช้งานพร้อมกันได้ โดยที่ Nคือขนาดของบัฟเฟอร์ ค่าเริ่มต้นของ เซมาฟอร์ readและwriteคือ 0 และ N ตามลำดับ

ทำซ้ำ{ รอ( อ่าน) ............ อ่านข้อมูล............ ส่งสัญญาณ( เขียน) } ในขณะที่( TRUE );

ทำซ้ำ{ รอ( เขียน) ............. กำลังเขียนข้อมูล............. ส่งสัญญาณ( อ่าน) } ในขณะที่( TRUE );

1. ผู้อ่านจะวิ่งตามผู้เขียนเพราะสัญญาณบอกตำแหน่งการอ่าน
2. โปรแกรมเขียนจะหยุดเขียนเมื่อสัญญาณเขียน (write semaphore) แสดงค่าเป็น 0
3. โปรแกรมอ่านจะหยุดอ่านเมื่อสัญญาณการอ่านลดลงเหลือ 0

ในลูปฝั่งผู้เขียน ค่าของเซมาฟอร์ฝั่งเขียนจะถูกส่งไปยังเซมาฟอร์ฝั่งอ่าน และในลูปฝั่งผู้อ่าน ค่าของเซมาฟอร์ฝั่งอ่านจะถูกส่งไปยังเซมาฟอร์ฝั่งเขียนเมื่อลูปเสร็จสิ้น

• ปัญหา ABA
• ปัญหาระหว่างผู้ผลิตและผู้บริโภค
• ปัญหาของนักปรัชญาที่รับประทานอาหาร
• ปัญหาของผู้สูบบุหรี่
• ปัญหาช่างตัดผมนอนหลับ
• ผู้อ่าน-ผู้เขียนติดขัด
• ลำดับล็อค
• อ่าน-คัดลอก-อัปเดต

• คำอธิบายเชิงอัลกอริทึมของปัญหาผู้อ่าน-ผู้เขียนข้อที่สาม