ฉันควรดูแลสภาพการแข่งขันซึ่งแทบไม่มีโอกาสเกิดขึ้นจริงหรือ

52

ลองพิจารณาบางอย่างเช่นแอปพลิเคชัน GUI ที่เธรดหลักกำลังอัปเดต UI เกือบจะทันทีและเธรดอื่น ๆ กำลังโพลข้อมูลผ่านเครือข่ายหรือสิ่งที่รับประกันว่าจะใช้เวลา 5-10 วินาทีเพื่อให้งานเสร็จ

ฉันได้รับคำตอบที่แตกต่างกันสำหรับเรื่องนี้ แต่บางคนบอกว่าถ้ามันเป็นสภาพการแข่งขันที่เป็นไปไม่ได้ทางสถิติไม่ต้องกังวลเลย แต่คนอื่น ๆ ก็บอกว่าถ้ามี 10 ^-53 % คุณไม่ได้อยู่ที่ตัวเลขนี่คือสิ่งที่ฉันเคยได้ยิน) เกี่ยวกับเวทมนตร์ของวูดูที่เกิดขึ้นเนื่องจากสภาพการแข่งขันให้ขอรับ / ปลดล็อกเธรดที่ต้องการเสมอ

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

programming-practices development-process multithreading

— l46kok
แหล่งที่มา

21

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

— Pieter B

27

ในฐานะนักฟิสิกส์ p <1E-140 หมายถึง p = 0 จะไม่เกิดขึ้นในจักรวาลนี้ 0.000000000000000000000000000000000000000000000000000000001% มีขนาดใหญ่กว่ามาก

— MSalters

15

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

— toasted_flakes

27

โอกาสหนึ่งในล้านเกิดขึ้นเก้าครั้งในสิบ

— Kaz Dragon

27

"เกือบจะไม่มีโอกาสเกิดขึ้นแน่นอน" หมายความว่ามันเกิดขึ้นในการผลิตเวลา 03:00 น. และมีแนวโน้มที่จะมีราคาแพงมาก

137

หากเป็นเหตุการณ์ 1 ใน 10 ^ 55 อย่างแท้จริงจะไม่จำเป็นต้องใช้รหัส นั่นแปลว่าถ้าคุณทำการผ่าตัด 1 ล้านครั้งต่อวินาทีคุณจะได้รับข้อผิดพลาดทุก ๆ 3 * 10 ^ 41 ปีซึ่งก็คือประมาณ 10 ^ 31 คูณอายุของจักรวาล หากแอปพลิเคชันของคุณมีข้อผิดพลาดเพียงครั้งเดียวในทุก ๆ ล้านล้านล้านล้านล้านอายุของเอกภพ

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

— ถ้ำจัสติน
แหล่งที่มา

66

ฉันนึกถึงความคิดเห็นที่ฉันอ่านเมื่อหลายปีก่อน แต่ไม่สามารถหาได้ในตอนนี้ "1 ในโอกาสนับล้านนั้นมักจะเป็นวันอังคารหน้า" +1 สำหรับการพูดว่า "ไม่มีที่ไหนใกล้ที่ไม่น่าจะเป็นไปได้"

— Bevan

2

+1 สำหรับการเดิมพัน วิธีที่ดีที่สุดในการจัดการกับสภาพการแข่งขันคือการกำจัดพวกเขา

— Blrfl

10

@Bevan "โอกาส 1 ล้านครั้งมักจะเป็นวันอังคารหน้า" ... เว้นแต่คุณจะเล่นลอตเตอรี :)

— dasblinkenlight

22

@dasblinkenlight แต่โอกาสของคนที่ชนะลอตเตอรี่ส่วนใหญ่จะเข้าใกล้ 100% ทำนายว่าใครคือผู้ที่ท้าทาย

— Bevan

3

@Bevan: ความคิดเห็นนั่นคือสิ่งที่เกิดขึ้นในใจของฉันเมื่อฉันอ่านคำถาม - นี่คือการอ้างอิง: blogs.msdn.com/b/larryosterman/archive/2004/03/30/104165.aspx

— Doc Brown

69

จากมุมมองด้านต้นทุน - ผลประโยชน์คุณควรเขียนรหัสเพิ่มเติมเฉพาะเมื่อมันได้รับผลประโยชน์เพียงพอ

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

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

— dasblinkenlight
แหล่งที่มา

20

+1: สำหรับการแยกความแตกต่างระหว่าง "ความล้มเหลวที่ดูเหมือนความล้มเหลว" และ "ความล้มเหลวที่ดูเหมือนประสบความสำเร็จ" ข้อมูลที่ไม่ถูกต้องนั้นรุนแรงมากขึ้นอยู่กับโดเมน

— deworde

2

+1 ทำให้เกิดความแตกต่างอย่างมากว่าผลลัพธ์ของสภาวะการแข่งขันจะเป็นอย่างไร

— อนุญาต

+1 ผลที่ตามมาของสภาพการแข่งขันควรเป็นปัจจัยสำคัญในการตัดสินใจว่าควรได้รับการแก้ไขหรือไม่ สภาพการแข่งขันที่อาจทำให้เครื่องบินตกแตกต่างจากสภาพที่อาจบังคับให้ผู้ใช้เปิดแอปพลิเคชันอีกครั้ง

— โผล่

1

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

— ลีโอ

1

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

— JesperE

45

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

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

— Karl Bielefeldt
แหล่งที่มา

1

นี่ด้วย! หลีกเลี่ยงการให้โปรแกรมเมอร์คนอื่น ๆ ไตร่ตรองเกี่ยวกับปัญหาที่อาจเกิดขึ้นเมื่ออ่านโค้ดของคุณโดยทำสิ่งที่จำเป็น (แม้ว่าจะเป็น 'ไม่น่าจะ' ล้มเหลว)

— Casey Kuball

ประเด็นของคุณได้รับการดำเนินการอย่างดี (การแก้ไขที่ทำตอนนี้เร็วกว่าและถูกกว่าที่ทำไว้ในภายหลัง) ยกเว้นว่าจะไม่เป็น "5 นาทีในการแก้ไขทันที"

— iconoclast

2

+1 สำหรับการชี้ให้เห็นว่าความน่าจะเป็นของสภาพการแข่งขันอาจขึ้นอยู่กับหลายปัจจัยดังนั้นแม้ว่ามันจะดูไม่น่าเป็นไปได้ในการกำหนดค่าของคุณมันอาจเกิดขึ้นบ่อยครั้งในระบบลูกค้า / บนระบบปฏิบัติการอื่น / ในรุ่นถัดไปเป็นต้น

— sleske

27

จัดหาและปลดล็อค การเปลี่ยนแปลงความน่าจะเป็นเปลี่ยนอัลกอริทึม มันเป็นนิสัยที่ไม่ดีที่จะเข้าไปและเมื่อมีอะไรผิดพลาดคุณไม่ต้องหยุดและสงสัยว่าคุณมีโอกาสผิด ...

— jmoreno
แหล่งที่มา

6

+1 สำหรับอัลกอริทึมเปลี่ยน ตอนนี้เมื่อคุณตระหนักถึงสภาพการแข่งขันความน่าจะเป็นต่ำ หลังจากหนึ่งปีเมื่อคุณลืมเกี่ยวกับสภาพการแข่งขันคุณอาจทำการเปลี่ยนแปลงรหัสของคุณซึ่งเปลี่ยนเวลาและความน่าจะเป็นของข้อผิดพลาดอย่างมีนัยสำคัญ

— ฟิล

13

และเธรดอื่น ๆ คือการสำรวจข้อมูลผ่านเครือข่ายหรือบางสิ่งที่รับประกันว่าจะใช้เวลา 5-10 วินาทีเพื่อให้งานเสร็จ

จนกว่าจะมีคนแนะนำเลเยอร์แคชเพื่อปรับปรุงประสิทธิภาพ ทันใดนั้นดอกยางอื่น ๆ ก็เข้ามาใกล้ทันใดและสภาพการแข่งขันปรากฏขึ้นบ่อยกว่านั้น

สิ่งนี้เกิดขึ้นไม่กี่สัปดาห์ที่ผ่านมาใช้เวลาประมาณ 2 วันในการพัฒนาเต็มรูปแบบเพื่อค้นหาข้อผิดพลาด

แก้ไขเงื่อนไขการแข่งขันเสมอถ้าคุณจำได้

— Michael Borgwardt
แหล่งที่มา

8

ง่ายเทียบกับที่ถูกต้อง

ในหลายกรณีความเรียบง่ายสำคัญกว่าความถูกต้อง มันเป็นปัญหาค่าใช้จ่าย

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

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

— ptyx
แหล่งที่มา

1

+1 สำหรับการบันทึกและล้มเหลวในช่วงต้นหากการแก้ไขโดยทันทีนั้นซับซ้อนเกินไป

— Martin Ba

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

— reirab

@ รีแรบฉันไม่เห็นด้วย หากคุณพิจารณาเหตุการณ์ที่เกิดขึ้นไม่บ่อยนักความล้มเหลวในการบันทึกจะคุ้มค่า ตัวอย่าง: หากแอปโทรศัพท์ของคุณมีอัตราความล้มเหลว 1/100 (เกิดความผิดพลาด) หากผู้ใช้สลับเครือข่ายในช่วงเปลี่ยนเดือนที่แน่นอน (1/31 23:59:00 -> 2/1 00:00:00) คุณ อาจจะไม่เคยได้ยินเรื่องนี้เลย แต่โอกาสในการเชื่อมต่อบนเซิร์ฟเวอร์ 1/10 ^ 9 จะไม่สามารถยอมรับได้ มันขึ้นอยู่กับ.

— ptyx

7

หากสภาพการแข่งขันของคุณเกี่ยวข้องกับความปลอดภัยคุณควรใช้รหัสเพื่อป้องกัน

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

แม้ว่าสภาพการแข่งขันจะมีโอกาสที่จะเกิดขึ้นแบบสุ่ม 10 ^ (- 80) แต่ก็อาจเป็นได้ว่าผู้โจมตีที่มุ่งมั่นมีโอกาสที่ดีในการสร้างเงื่อนไขดังกล่าวโดยเจตนาและเทียม

— บริสตอ
แหล่งที่มา

6

Therac-25!

นักพัฒนาในโครงการ Therac-25 ค่อนข้างมั่นใจในช่วงเวลาระหว่าง UI และปัญหาที่เกี่ยวข้องกับอินเตอร์เฟสในเครื่อง XRAY

พวกเขาไม่ควรได้รับ

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับภัยพิบัติซอฟต์แวร์แห่งชีวิตและความตายที่มีชื่อเสียงได้ที่:

http://www.youtube.com/watch?v=izGSOsAGIVQ

หรือ

http://en.wikipedia.org/wiki/Therac-25

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

หากคุณเลือกที่จะสร้างรหัสของคุณให้มีอายุการใช้งาน (และฟังดูเหมือนว่าคุณมี) คุณควรพิจารณากฎของมัวร์ที่สามารถลบศูนย์ได้หลายศูนย์ทุก ๆ สองสามปีเนื่องจากคอมพิวเตอร์ภายในหรือภายนอกระบบของคุณเร็วขึ้น หากคุณจัดส่งสำเนาหลายพันชุดให้ตัดเลขศูนย์ออก หากผู้ใช้ดำเนินการนี้ทุกวัน (หรือรายเดือน) เป็นเวลาหลายปี ถ้ามันถูกใช้ในที่ที่มีเส้นใยของ Google แล้วจะเป็นอย่างไร? หาก UI ของขยะรวบรวมการทำงานของ GUI กลางนั่นจะส่งผลกระทบต่อการแข่งขันหรือไม่? คุณใช้ไลบรารี Open Source หรือ Windows หลัง GUI ของคุณหรือไม่ การอัปเดตที่นั่นจะมีผลต่อเวลาหรือไม่

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

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

ดูเหมือนว่าการคำนวณความน่าจะเป็นมาจากคนอื่น พวกเขารู้รหัสของคุณหรือไม่และคุณรู้จักพวกเขามากพอที่จะเชื่อมั่นว่าไม่ได้ทำผิด ถ้าฉันคำนวณความน่าเชื่อถือ 99.99997% สำหรับบางสิ่งบางอย่างฉันอาจคิดถึงกลับไปที่ชั้นเรียนสถิติวิทยาลัยของฉันและจำไว้ว่าฉันไม่ได้รับ 100% เสมอไปและถอยออกไปไม่กี่เปอร์เซ็นต์จากการประเมินความน่าเชื่อถือส่วนบุคคลของฉันเอง

— DeveloperDon
แหล่งที่มา

1

+1 สำหรับการพูดถึง Therac-25 บทเรียนสำคัญมากมายที่นี่

— สจวร์ตมาร์ค

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

— marktani

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

— DeveloperDon

4

มันจะไม่จำเป็นอย่างสิ้นเชิงหรือต่อต้านการเพิ่มรหัสบรรทัดเพิ่มเติมเพื่อขัดขวางการอ่าน?

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

ไม่ว่าคุณจะจัดการกับวิธีใด (โดยการบันทึกการจัดเก็บหรือเพิ่มการล็อค - ขึ้นอยู่กับราคา) คุณจะประหยัดเวลาโปรแกรมเมอร์อื่น ๆ เมื่อดูรหัส

— Casey Kuball
แหล่งที่มา

3

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

ไม่ค่อยมีคำตอบ 'ขนาดเดียวที่เหมาะกับทุกคน' สำหรับคำถามประเภทนี้เพราะพวกเขาไม่ใช่คำถามการเขียนโปรแกรม แต่แทนที่จะเป็นคำถามเชิงเศรษฐศาสตร์

— GrandmasterB
แหล่งที่มา

3

"ระบบควบคุมการบินสำหรับยานพาหนะอวกาศต่อไป" แน่นอน

— deworde

อาจ ... แน่นอน ... มันขึ้นอยู่กับว่าใครอยู่ในจรวด :-)

— GrandmasterB

3

ใช่คาดหวังสิ่งที่ไม่คาดคิด ฉันใช้เวลาหลายชั่วโมง (ในรหัสคนอื่น ๆ ^^) การติดตามเงื่อนไขที่ไม่ควรเกิดขึ้น

สิ่งต่าง ๆ เช่นมีอย่างอื่นมักจะมีค่าเริ่มต้นในกรณีเริ่มต้นตัวแปร (ใช่จริงๆ .. ข้อผิดพลาดเกิดขึ้นจากนี้) ตรวจสอบลูปของคุณสำหรับตัวแปรที่นำมาใช้ซ้ำสำหรับการทำซ้ำแต่ละครั้ง ฯลฯ

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

— พอล
แหล่งที่มา

3

เพียงแก้ไขมัน

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

ลูกค้าบางคนจะตัดสินใจว่าจะใช้งานอะไรซักอย่างหนึ่งวันซึ่งจะทำให้ CPU ตลอดเวลาสำหรับเธรด "เร็ว" ในขณะที่ปล่อยให้เธรดทำงานช้าและคุณจะต้องเสียใจ :)

— JohnB
แหล่งที่มา

1

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

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

— Mark Hurd
แหล่งที่มา

1

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

— Steve Bennett

0

ฉันคิดว่าถ้าคุณรู้อยู่แล้วว่ามันจะเกิดขึ้นได้อย่างไรและทำไมมันอาจจะจัดการกับมันได้ นั่นคือถ้าไม่ใช้ทรัพยากรจำนวนมาก

— Sjaak van der Heide
แหล่งที่มา

0

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

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

— Sylwester
แหล่งที่มา

0

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

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

Receive event from device:
{
    Record event details.
    Enqueue event in the queuing thread.
    Acknowledge the event.
}

Queueing thread receives an event:
{
    Retrieve event details.
    Process event.
    Send next command to device.
}

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

เมื่อกำหนดให้มันมีผลกับลูกค้าหนึ่งรายในการกำหนดค่าเดียวฉันจึงอัปเดตThread.Sleep(1000)ปัญหาที่เกิดขึ้น ไม่มีปัญหาตั้งแต่นั้นมา

— มือ-E-อาหาร
แหล่งที่มา