มีความคิดผิด ๆ อะไรบ้างที่ทำให้คนไม่ชอบใช้กระทู้? [ปิด]

12

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

ปิดให้บริการใน8 ปีที่ผ่านมา

การใช้เธรดในโปรแกรมนั้นยาก แต่ทำไมถึงมีบางคนที่จะไม่ติดตั้งแม้ว่าจะมีความต้องการที่ชัดเจน

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

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

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

ดังนั้นสิ่งที่คุณได้ยินเกี่ยวกับเธรดที่เป็นเท็จคืออะไร

multithreading

— Tony The Lion
แหล่งที่มา

Misfits และ underachievers ไม่สามารถจัดการหัวข้อ คำถามจริงคือคุณจะทำอะไรเกี่ยวกับเรื่องนี้?

— งาน

3

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

— tp1

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

— user1172763

19

การทำเกลียวนั้นยาก

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

ไม่ใช่ว่าเป็นไปไม่ได้

— Steven Evers
แหล่งที่มา

2

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

11

@ ก่อนหน้าฉันคาดหวังว่าคำจำกัดความของคนจำนวนมากคือ "คุณต้องใช้เวลามากพอที่จะเข้าใจ"

— Benjol

1

Threading จะได้รับจะมีจำนวนมากขึ้นกับทีพีแอลและawait/ asyncคำหลัก :)

— ราเชล

@Pierre 303: เมื่อคุณใช้เวลาพอที่จะเข้าใจว่ามันยังคงยากและในความเป็นจริงคนที่เข้าใจดีที่สุดมีแนวโน้มที่จะหลีกเลี่ยงได้มากที่สุด

— Michael Borgwardt

9

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

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

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

หมายเหตุถึงตนเอง: เขียนอัลกอริทึมแบบขนาน ... ขอบคุณ

— Droogans

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

— rwong

3

เธรดแก้ปัญหาทั้งหมดของคุณ

หากคุณมีปัญหาด้านประสิทธิภาพคุณไม่ควรข้ามไปที่เธรด

หัวข้อที่มีน้ำหนักเบา

หัวข้อมีน้ำหนักเบาในสิบและยี่สิบ การวางไข่หลายพันกระทู้ไม่ได้

การทำเกลียวเป็นเรื่องง่าย [Java]

มันง่ายที่จะสร้างกระทู้ซึ่งไม่ได้หมายความว่าคุณจะได้รับประโยชน์จากมัน

— Josh K
แหล่งที่มา

เพียงเพื่อบันทึก Mac OS จะไม่ยอมให้คุณ (ในการติดตั้งเริ่มต้น) สร้างหัวข้อมากกว่า 512 หัวข้อ

— zneak

1

ขึ้นอยู่กับภาษาของคุณ การวางไข่ 1 ล้านเธรดใน Erlang นั้นแทบจะสังเกตไม่เห็นแม้แต่บนแล็ปท็อปรุ่นเก่า และที่จริงแล้วสิ่งเหล่านี้ไม่ได้เป็นเพียงแค่เธรดเท่านั้น แต่ยังเป็นกระบวนการที่เต็มไปด้วยความหนักเบากว่าเธรด นอกเหนือจากตัวนับโปรแกรมของตนเองและ call stack (ซึ่งเป็นสิ่งเดียวที่เธรดมี) พวกเขายังมีฮีปของตัวเองและแม้แต่ตัวเก็บขยะของตัวเอง

— Jörg W Mittag

4

@ Jörg W Mittag: ฉันสับสนกับความคิดเห็นของคุณ erlang เปลี่ยนวิธีที่ระบบปฏิบัติการสร้างเธรดหรือกระบวนการอย่างไร

— Steven Evers

1

@SnOrfus: Erlang ไม่ได้ใช้เธรด OS มีการใช้งาน Erlang หลักสามแบบในขณะนี้: BEAM, HiPE และ Erjang BEAM และ HiPE เป็นการใช้งานแบบเนทีฟ (ซึ่งสามารถทำงานได้โดยไม่มีระบบปฏิบัติการใด ๆ เลย) และใช้กระบวนการของตนเอง Erjang ทำงานบน JVM และใช้กระบวนการโดยใช้ห้องสมุด Kilim ที่ยอดเยี่ยม

— Jörg W Mittag

@ Jörg W Mittag: พิจารณาคำถามของฉันprogrammers.stackexchange.com/questions/28453/…ฉันพบว่าสิ่งนี้น่าสนใจมาก ขอบคุณ.

— Steven Evers

1

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

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

— Kamil Szot
แหล่งที่มา

ข้อบกพร่องที่ไม่สามารถแก้ไขได้? ฉันไม่เคยเห็นหนึ่งในนั้นมาก่อนเลย ..

— adamk

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

— Kamil Szot

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

— slebetman

1

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

สิ่งเท็จ: -
1) แนวคิดที่สับสนของเธรดที่ปลอดภัยและฟังก์ชันการเข้าใหม่
2) เธรดดูดีบนกระดาษ แต่ยากที่จะนำมาใช้

— Manoj R
แหล่งที่มา

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

— Steven Evers

จริงๆแล้วคุณไม่จำเป็นต้องล็อคหรือทำข้อมูลให้ตรงกัน นอกจากนี้ยังมีแบบจำลองการส่งข้อความ (เช่น erlang, scala) และโมเดล STM (เช่น clojure) และนอกเหนือจากนั้นยังมีโครงสร้างข้อมูลที่ปลอดภัยสำหรับเธรดที่ไม่ต้องการการล็อก (ConcurrentHashMap ใน java) และปรมาณูแบบดั้งเดิมที่ไม่ต้องการการล็อค

— เควิน

1

หากคุณไม่ต้องการเขียนการทดสอบสำหรับโค้ดของคุณอย่าใช้เธรด

หัวข้อไม่เหมาะสำหรับโปรแกรมเมอร์ 'คัดลอกและวาง' ที่ไม่เข้าใจพื้นฐานของระบบปฏิบัติการและสถาปัตยกรรมคอมพิวเตอร์ เนื่องจาก 90% ของโปรแกรมเมอร์คุ้นเคยกับ Java คนเหล่านี้จึงไม่ใช่คนที่ควรใช้เธรด Java ทำให้เธรด "ง่าย" แต่ฉันเห็นโปรแกรมเมอร์จำนวนมากที่เพิ่งคิดว่าถ้าพวกเขาใช้โครงสร้างที่ซิงโครไนซ์รหัสของพวกเขาจะทำงานในเธรด .... uhm no

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

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

คุณสามารถแนะนำทรัพยากรบางอย่างเกี่ยวกับวิธีการทำเธรดให้ถูกต้องได้หรือไม่?

— Jonathan

ฉันแน่ใจว่าสิ่งนี้ได้รับการแก้ไขแล้ว ลองเริ่มที่นี่stackoverflow.com/questions/660621/threading-best-practices

— cmcginty

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

— Zachary K

1

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

ฉันไม่เห็นว่าสถานการณ์นี้แสดงถึงความจำเป็นในการใช้เธรดด้วยเหตุผลอย่างน้อย 4 ประการ:

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

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

— ไม่มีโอกาส
แหล่งที่มา

1

จุดแรกของคุณทำให้ฉันนึกถึงข้อผิดพลาดของการคำนวณแบบกระจาย ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ) ผู้ใช้จำนวนมากที่น่าสะพรึงกลัวอาจเริ่มคลิกอย่างดุเดือดเมื่อพวกเขาต้องรอมากกว่า 1 หรือ 2 วินาทีจากจุดที่ 2 ของคุณสำหรับอินเทอร์เฟซที่ไม่ตอบสนองทำให้สิ่งเลวร้ายลง

— รักษาความปลอดภัย

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

— NoChance

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

— รักษาความปลอดภัย

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

— รักษาความปลอดภัย

1

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

— NoChance