คำถามติดแท็ก concurrency

คำถามเกี่ยวกับปัญหาของการเกิดพร้อมกันเช่นการซิงโครไนซ์และการหยุดชะงัก

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

2
กระบวนการ CCS สำหรับตู้กดน้ำที่มีราคาแตกต่างกันสองแบบ
ตู้กดน้ำต้องให้ผู้ใช้ใส่เหรียญ ( ) จากนั้นกดปุ่มหนึ่งในสามปุ่ม:ขอถ้วยชา , เหมือนกันสำหรับกาแฟ และขอเงินคืน (เช่นเครื่องให้เงินคืน: ) เครื่องจ่ายนี้สามารถสร้างแบบจำลองโดยกระบวนการCCSต่อไปนี้:c¯c¯\bar cd¯tead¯tea\bar d_{\text{tea}}eteaeteae_{\text{tea}}r¯r¯\bar rb¯b¯\bar b M=defc.(dtea.e¯tea.M+dcoffee.e¯coffee.M+r.b¯.M)M=defc.(dtea.e¯tea.M+dcoffee.e¯coffee.M+r.b¯.M) M \stackrel{\mathrm{def}}= c.(d_{\text{tea}}.\bar e_{\text{tea}}.M + d_{\text{coffee}}.\bar e_{\text{coffee}}.M + r.\bar b.M) สงครามกลางเมืองยกระดับราคากาแฟเป็นสองเหรียญในขณะที่ราคาของชายังคงอยู่หนึ่งเหรียญ เราต้องการเครื่องที่ได้รับการดัดแปลงซึ่งให้กาแฟหลังจากเหรียญสองเหรียญและได้รับการคืนเงินหลังจากเหรียญหนึ่งหรือสองเหรียญ เราจะจำลองเครื่องที่ดัดแปลงด้วยกระบวนการ CCS ได้อย่างไร

3
ทำไมการใช้งาน mutex ส่วนใหญ่จึงไม่ยุติธรรม?
ความเข้าใจของฉันคือการใช้งาน mutex ที่นิยมมากที่สุด (เช่น std :: mutex ใน C ++) ไม่รับประกันความเป็นธรรม - นั่นคือพวกเขาไม่รับประกันว่าในกรณีของการช่วงชิงการล็อคจะถูกรับโดยเธรดตามลำดับที่พวกเขา เรียกว่าล็อค () ในความเป็นจริงมันเป็นไปได้ (แม้จะหวังว่าผิดปกติ) ว่าในกรณีที่มีการโต้แย้งสูงบางกระทู้ที่รอรับ mutex อาจไม่เคยได้รับ นี่ดูเหมือนว่าพฤติกรรมที่ไม่ช่วยเหลือฉัน - ดูเหมือนว่า mutex ที่ยุติธรรมจะให้ผลการทำงานที่สอดคล้องกับสิ่งที่โปรแกรมเมอร์ต้องการ / คาดหวัง เหตุผลที่กำหนดว่าทำไมโดยทั่วไปแล้วการใช้งาน mutex จะไม่ถูกนำมาใช้เพื่อความยุติธรรมคือ "ประสิทธิภาพ" แต่ฉันต้องการทำความเข้าใจให้ดีขึ้นว่าอะไรคือความหมาย - โดยเฉพาะอย่างยิ่งการผ่อนคลายข้อกำหนดความเป็นธรรมของ mutex จะปรับปรุงประสิทธิภาพอย่างไร ดูเหมือนว่า mutex ที่ "ยุติธรรม" จะใช้งานได้ง่ายเพียงแค่มี lock () ต่อท้ายเธรดการเรียกไปยังส่วนท้ายของรายการที่เชื่อมโยงของ mutex ก่อนที่จะวางเธรดเข้าสู่โหมดสลีปแล้วปลดล็อก () ป๊อปเธรดถัดไปจาก หัวของรายการเดียวกันนั้นและปลุกมันขึ้นมา ฉันขาดความเข้าใจในการใช้งาน …

1
พิธีการในการเขียนโปรแกรมพร้อมกันและ / หรือกระจาย?
พื้นหลังของฉันมาจากภาษาที่จำเป็นส่วนใหญ่เป็น C, C ++ และ Python ฉันเลือกสคาลาเออร์แลงและแฮสเค็ลสักสองสามปีต่อมาและตั้งแต่นั้นมาก็เริ่มให้ความสนใจในการเขียนโปรแกรมเชิงฟังก์ชั่นและพิธีการทางด้านหลัง ฉันยังสนใจในการเขียนโปรแกรมพร้อมกันและกระจายและได้รับการดูในพิธีการหลังโดยเฉพาะอย่างยิ่งผู้ที่ได้เห็น "แสงของวัน" อย่างน้อยนิด (เช่นการใช้งานจริงหรืออย่างน้อยการใช้งานที่ไหนสักแห่ง) จนถึงตอนนี้ฉันรู้เกี่ยวกับกระบวนการสื่อสารตามลำดับ, โมเดลนักแสดง, พีชคณิตของกระบวนการสื่อสาร, และแคลคูลัสของระบบการสื่อสาร ในบรรดาสิ่งเหล่านี้ฉันรู้ว่าโมเดลนักแสดงได้ตระหนักในภาษาเช่น Erlang, Scala และ Haskell ฉันสงสัยว่ามีรากฐานฉันควรเรียนรู้และฝึกฝนก่อนที่จะจัดการกับเขตข้อมูลเหล่านี้หรือไม่หากมี "คลาสสิค" ที่ฉันควรจะศึกษาก่อนและหากมีคนอื่นที่เป็นที่นิยมที่ฉันอาจพลาดไป

3
เป็นไปได้ที่จะพิสูจน์ความปลอดภัยของด้ายหรือไม่
ให้โปรแกรมประกอบด้วยตัวแปรและคำแนะนำที่แก้ไขตัวแปรเหล่านี้และดั้งเดิมการซิงโครไนซ์ (จอภาพ, mutex, การซิงโครไนส์ของ java หรือการล็อกของ C #) เป็นไปได้ไหมที่จะพิสูจน์ว่าโปรแกรมดังกล่าวปลอดภัยหรือไม่? มีรูปแบบที่เป็นทางการสำหรับอธิบายสิ่งต่าง ๆ เช่นความปลอดภัยของด้ายหรือสภาพการแข่งรถหรือไม่?

2
อัลกอริทึมการแยกซึ่งกันและกันของ 2 กระบวนการของ Peterson นั้นเป็นสาเหตุของกระบวนการที่กำลังจะตายหรือไม่?
ฉันคิดว่าในอัลกอริทึมของ Petersonสำหรับการยกเว้นซึ่งกันและกันหากกระบวนการก่อนเข้าสู่ส่วนที่สำคัญคือการตายหรือถูกยกเลิกกระบวนการอื่นจะวนซ้ำตลอดไปโดยรอที่จะเข้าสู่ส่วนที่สำคัญ ในรูปภาพหากกระบวนการ 1 หยุดทำงานส่วนที่เหลือของกระบวนการหลังกระบวนการ 1 จะดำเนินการจนถึงตำแหน่งที่กระบวนการ 1 เป็น แต่วนรอบ จะเกิดอะไรขึ้นถ้ากระบวนการที่มาถึงส่วนที่สำคัญเสียชีวิตก่อนที่จะออกไป
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.