ฉันคิดว่า บริษัท ของคุณไม่ควรใช้มัลติเธรด
หลังจากทำโครงงานแบบมัลติเธรดจำนวนมากฉันพบว่าสองเทคนิคมีความสำคัญต่อการทำให้สิ่งต่าง ๆ ทำงานได้ ก่อนอื่นต้องเขียนรหัสให้ถูกต้อง ทุกฟิลด์จะต้องตรวจสอบด้วยตนเองเพื่อให้แน่ใจว่ามีการประกาศอย่างถูกต้องและซิงโครไนซ์อย่างเหมาะสมทุกที่ที่อ้างอิง (คำเตือน: ฉันกำลังทำให้สิ่งต่าง ๆ ง่ายขึ้นเล็กน้อยที่นี่เพื่อให้คำตอบของฉันสั้น - หรือในอัตราใดก็ตามสั้นกว่า) ประการที่สองรหัสจะต้องถูกทดสอบโดยการรันมันแบนในเครื่องเดียวและมัลติคอร์ - หลายนาทีโดยใช้ 100% ของแต่ละคอร์ (และถ้าใช้เพียง 2% ของแต่ละคอร์เหมือนที่ทำกับฉันบ่อยนั่นเป็นข้อผิดพลาดด้วย)
คุณอาจจัดการสิ่งนี้ได้ แต่องค์กรของคุณทำไม่ได้ แม้ว่าพวกเขาจะเข้าใจปัญหาที่พวกเขาไม่มีพวกเขาก็ไม่มีความเชี่ยวชาญ
ภาษาส่วนใหญ่มีวิธีการหลีกเลี่ยงปัญหานี้ หากคุณมีเครื่องอ่านซ็อกเก็ตซึ่งมักจะมีเธรดของตัวเองให้รับข้อมูลไปยังเธรดหลักอย่างรวดเร็วและง่ายดายที่สุด ดีกว่ามองหาคลาสระบบ / ฟังก์ชั่นที่จะจัดการเธรดส่วนของการอ่านให้คุณ ใช้คิวที่เรียกใช้ "เหตุการณ์" ที่อยู่ติดกันเหมือนกับ GUI API ส่วนใหญ่ (ใช้คิวเหตุการณ์ของ GUI API เองสำหรับเรื่องนั้น) หากคุณต้องการการประมวลผลแบบขนานคุณอาจพบ "thread ผู้ทำงาน" บางประเภทที่จะช่วยให้คุณเก็บข้อมูล / เขตข้อมูลไว้ในเธรดเดียวจัดการการถ่ายโอนทั้งหมดให้คุณ
เน้นถึงอันตรายทั้งหมดของการทำมัลติเธรด (เรื่องราวที่น่ากลัว: ข้อผิดพลาดที่ชื่นชอบเกี่ยวข้องกับสองบรรทัดเช่น: int i = 5; i = i * i;ซึ่งทำให้iมีค่าเท่ากับ 35. หนึ่งที่ฉันเห็นมากคือ: if (thing != null) thing.reset();การขว้างข้อยกเว้นตัวชี้โมฆะ) ฉันคิดว่าความหวังเดียวของคุณคือทำให้พวกเขาเข้าใจว่าพวกเขาเข้าใจ ก้าวเข้าสู่โลกใหม่ที่แปลกใหม่และบางทีพวกเขาควรก้าวถอยหลังครั้งใหญ่
ฉันไม่แน่ใจว่าจริง multithreading ควรได้รับการจัดการ หากงานสามารถมอบให้กับคนคนหนึ่งและทุกอย่างที่พวกเขาทำไปถ้าพวกเขาล้มเหลวก็ดี แต่ทีมจะต้องแข็งแกร่งพอ ๆ กับสมาชิกที่อ่อนแอที่สุดและแม้แต่โปรแกรมเมอร์ที่ดีก็จะมีปัญหากับการใช้มัลติเธรดที่เต็มเปี่ยม ฉันหวังว่าคนภาษาจะหาวิธีที่จะทำให้มันปลอดภัย ฉันเห็นซอฟต์แวร์ที่เป็นประโยชน์ออกมาแล้ว แต่ฉันคิดว่ามันเป็นการดีที่สุดที่จะหลีกเลี่ยงการทำงานแบบมัลติเธรดเว้นแต่ว่าเวลาดำเนินการเป็นเรื่องสำคัญและมีโปรแกรมเมอร์หรือทีมที่ได้รับการพิสูจน์แล้ว