จะอธิบายได้อย่างไรว่าทำไมมัลติเธรดจึงยาก

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

เมื่อคุณเริ่มกังวลเกี่ยวกับการหยุดชะงักและสภาพการแข่งขันฉันพบว่ามันยากมาก แต่เจ้านายดูเหมือนจะไม่เห็นคุณค่าในเรื่องนี้ - ฉันไม่คิดว่าเขาจะเคยเจอสิ่งนี้มาก่อน เพียงตบล็อคมันเป็นทัศนคติที่สวยมาก

ดังนั้นฉันจะแนะนำเขาอย่างไรหรืออธิบายว่าทำไมเขาถึงประเมินความซับซ้อนของการเกิดพร้อมกันการขนานและมัลติเธรด หรือบางทีฉันผิด

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

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

2. "ตบล็อคมัน" เป็นวิธีแก้ปัญหาเล็กน้อย ... มันแก้ปัญหาทั้งหมดของคุณหากคุณไม่กังวลเกี่ยวกับประสิทธิภาพ พยายามที่จะแสดงให้เห็นถึงประสิทธิภาพการทำงานที่จะเป็นเช่นถ้า Amazon ต้องล็อคชายฝั่งตะวันออกทั้งหมดเมื่อใดก็ตามที่ใครบางคนในแอตแลนตาสั่งซื้อหนังสือเล่มหนึ่ง!

มัลติเธรดเป็นเรื่องง่าย การเข้ารหัสแอปพลิเคชันสำหรับมัลติเธรดเป็นเรื่องง่ายมาก

มีเคล็ดลับง่ายๆและนี่คือการใช้คิวข้อความที่ออกแบบอย่างดี (ไม่ได้ม้วนของคุณเอง) ในการส่งผ่านข้อมูลระหว่างหัวข้อ

ส่วนที่ยากคือพยายามที่จะมีหลายกระทู้ที่ปรับปรุงวัตถุที่ใช้ร่วมกันอย่างน่าอัศจรรย์ในบางวิธี นั่นคือเมื่อมันได้รับข้อผิดพลาดได้ง่ายเพราะคนไม่ใส่ใจกับสภาพการแข่งขันที่มีอยู่

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

สิ่งที่ยากคือการออกแบบอัลกอริทึมที่ทำงานได้ดีเมื่อส่งข้อมูลระหว่างคิวต่างๆ นั่นเป็นเรื่องยาก แต่กลไกของเธรดที่มีอยู่ร่วม (ผ่านคิวที่แชร์) นั้นง่าย

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

หากคุณต้องการแสดงให้เห็นถึงปัญหาการอัพเดทออบเจกต์ร่วมนั้นเป็นเรื่องง่าย นั่งบนโต๊ะพร้อมกับการ์ดกระดาษมากมาย เขียนชุดการคำนวณอย่างง่าย - สูตรง่าย ๆ 4 หรือ 6 สูตร - โดยมีที่ว่างมากมายในหน้ากระดาษ

นี่คือเกม คุณแต่ละคนอ่านสูตรเขียนคำตอบแล้วใส่คำตอบลงไป

คุณแต่ละคนจะทำงานครึ่งหนึ่งใช่มั้ย คุณเสร็จครึ่งเวลาใช่มั้ย

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

มีหลายวิธีในการสร้างสภาพการแข่งขันที่มีทรัพยากรไม่ดีหรือไม่ถูกล็อค

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

การเขียนโปรแกรมแบบมัลติเธรดอาจเป็นทางออกที่ยากที่สุดในการเกิดพร้อมกัน โดยทั่วไปแล้วมันค่อนข้างเป็นนามธรรมในระดับต่ำของสิ่งที่เครื่องทำ

มีหลายวิธีเช่นโมเดลนักแสดงหรือ(ซอฟต์แวร์) หน่วยความจำธุรกรรมซึ่งง่ายกว่ามาก หรือทำงานกับโครงสร้างข้อมูลที่เปลี่ยนแปลงไม่ได้ (เช่นรายการและต้นไม้)

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

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

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

ฉันคิดว่ามันไม่มีมุมมองทางเทคนิคสำหรับคำถามนี้ - IMO มันเป็นปัญหาของความไว้วางใจ เรามักถูกขอให้สร้างแอพที่ซับซ้อนเช่น - โอ้ฉันไม่รู้ - เช่น Facebook ฉันได้ข้อสรุปว่าหากคุณต้องอธิบายความซับซ้อนของงานที่ไม่ได้ฝึกหัด / จัดการ - สิ่งที่เลวร้ายในเดนมาร์ก

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

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

การทดลองทางความคิดอย่างง่าย ๆ เพื่อทำความเข้าใจการหยุดชะงักคือปัญหา " นักปรัชญาการรับประทานอาหาร " หนึ่งในตัวอย่างที่ฉันมักจะใช้เพื่ออธิบายว่าสภาพการแข่งขันที่เลวร้ายสามารถเป็นสถานการณ์Therac 25ได้อย่างไร

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

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

ดังนั้นแอปพลิเคชันที่ทำงานพร้อมกันที่ถูกต้องเพียงอย่างเดียวจึงเป็นสิ่งที่ถูกต้องซึ่งพิสูจน์ได้ว่าบางสิ่งที่ไม่ได้รับการฝึกฝนในการพัฒนาซอฟต์แวร์ เป็นผลให้คำตอบของ S.Lot เป็นคำแนะนำทั่วไปที่ดีที่สุดเนื่องจากการส่งข้อความค่อนข้างง่ายต่อการพิสูจน์ความถูกต้อง

คำตอบสั้น ๆ ในสองคำ: NONDETERMINISM ที่สังเกตเห็นได้

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

• การเขียนโปรแกรมแบบลำดับ : วิธีการพื้นฐานที่ไม่มีการทำงานพร้อมกัน;
• การประกาศพร้อมกัน : สามารถใช้งานได้เมื่อไม่มีการโน้มน้าวไม่เชื่อฟัง
• การส่งข้อความพร้อมกัน : ข้อความที่เกิดขึ้นพร้อมกันที่ส่งผ่านระหว่างเอนทิตีจำนวนมากโดยที่แต่ละเอนทิตีประมวลผลข้อความภายในตามลำดับ
• สถานะที่ใช้ร่วมกันที่ใช้ร่วมกัน : เธรดการปรับปรุงวัตถุที่ใช้ร่วมกันแบบพาสซีฟโดยใช้การกระทำอะตอมมิกอย่างหยาบเช่นการล็อกการตรวจสอบและการทำธุรกรรม

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

แต่การขาด nondeterminism ที่สังเกตได้หมายความว่ามีปัญหาบางอย่างที่เราไม่สามารถแก้ไขได้ด้วยการใช้ภาวะพร้อมกันที่เปิดเผย นี่คือจุดที่ทั้งสองวิธีสุดท้ายไม่ง่ายนักเข้ามาเล่น ส่วนที่ไม่ง่ายอย่างนั้นเป็นผลมาจากความไม่เชื่อในพระเจ้า ตอนนี้พวกเขาทั้งคู่ตกอยู่ภายใต้แบบจำลองที่เกิดขึ้นพร้อมกันและยังเทียบเท่ากับการแสดงออก แต่เนื่องจากจำนวนแกนประมวลผลต่อ CPU เพิ่มขึ้นเรื่อย ๆ ดูเหมือนว่าอุตสาหกรรมจะให้ความสนใจมากขึ้นเมื่อเร็ว ๆ นี้ในการส่งข้อความพร้อมกันซึ่งสามารถเห็นได้ในการเพิ่มขึ้นของห้องสมุดส่งข้อความ (เช่นAkkaสำหรับ JVM) หรือภาษาโปรแกรม (เช่นErlang ) .

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

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

ฉันได้รับการสอนครั้งแรกว่ามันอาจทำให้เกิดปัญหาโดยการเห็นโปรแกรมง่าย ๆ ที่เริ่ม 2 เธรดและให้ทั้งคู่พิมพ์ไปที่คอนโซลในเวลาเดียวกันตั้งแต่ 1-100 แทน:

1
1
2
2
3
3
...

คุณได้อะไรแบบนี้:

1
2
1
3
2
3
...

เรียกใช้อีกครั้งและคุณอาจได้รับผลลัพธ์ที่แตกต่างกันโดยสิ้นเชิง

พวกเราส่วนใหญ่ได้รับการฝึกฝนให้คิดว่ารหัสของเราจะดำเนินการตามลำดับ ด้วยมัลติเธรดส่วนใหญ่เราไม่สามารถใช้สิ่งนี้เพื่อรับ "ออกจากกล่อง"

ลองใช้ค้อนหลายตัวเพื่อบดในเล็บที่มีระยะห่างอย่างใกล้ชิดพร้อมกันโดยไม่ต้องมีการสื่อสารระหว่างคนที่ถือค้อน ... (สมมติว่าพวกเขาปิดตา)

ยกระดับเรื่องนี้เพื่อสร้างบ้าน

ลองนอนในตอนกลางคืนแล้วจินตนาการว่าคุณเป็นสถาปนิก :)

ส่วนที่ง่าย: ใช้มัลติเธรดกับคุณสมบัติร่วมสมัยของกรอบระบบปฏิบัติการและฮาร์ดแวร์เช่นเซมาฟอร์คิวคิวที่เชื่อมต่อกันประเภทอะตอมชนิดบรรจุกล่องเป็นต้น

ส่วนที่ยาก: ใช้งานฟีเจอร์เหล่านั้นเองโดยไม่ใช้ฟีเจอร์ในตอนแรกอาจยกเว้นความสามารถที่ จำกัด ของฮาร์ดแวร์ไม่กี่ตัว