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

รวมทรัพยากรในขีด จำกัด ที่กำหนดและมอบหมายงานให้กับพนักงานที่เปิดโดยอัตโนมัติ

9
หากอินเทอร์เฟซของฉันต้องส่งคืนงานเป็นวิธีที่ดีที่สุดในการปรับใช้งานที่ไม่ดำเนินการอย่างไร
ในโค้ดด้านล่างเนื่องจากอินเทอร์เฟซคลาสLazyBarจะต้องส่งคืนภารกิจจากเมธอดของมัน (และสำหรับเหตุผลที่ไม่สามารถเปลี่ยนแปลงได้) หากLazyBarการติดตั้งใช้งานผิดปกติเกิดขึ้นกับการทำงานที่รวดเร็วและพร้อมกัน - วิธีใดที่ดีที่สุดในการส่งคืนภารกิจที่ไม่มีการดำเนินการจากเมธอด? ฉันได้ไปTask.Delay(0)ข้างล่างนี้ แต่ฉันอยากจะรู้ว่าสิ่งนี้มีผลข้างเคียงของการทำงานหรือไม่ถ้าฟังก์ชั่นนี้มีการเรียกใช้มาก (เพื่อประโยชน์ในการโต้แย้งพูดหลายร้อยครั้งต่อวินาที): น้ำตาลซินแทติกติกนี้ไม่ทำให้ลมออกมาเป็นเรื่องใหญ่หรือไม่? มันเริ่มอุดตันกลุ่มแอปพลิเคชันของฉันหรือไม่ คอมไพเลอร์มีดเพียงพอที่จะจัดการกับDelay(0)แตกต่างกันหรือไม่? จะreturn Task.Run(() => { });แตกต่างกันอย่างไร มีวิธีที่ดีกว่า? using System.Threading.Tasks; namespace MyAsyncTest { internal interface IFooFace { Task WillBeLongRunningAsyncInTheMajorityOfImplementations(); } /// <summary> /// An implementation, that unlike most cases, will not have a long-running /// operation in 'WillBeLongRunningAsyncInTheMajorityOfImplementations' /// </summary> internal …

12
จำนวนกระทู้มีมากเกินไป
ฉันกำลังเขียนเซิร์ฟเวอร์และฉันส่งแต่ละการกระทำของลงในเธรดแยกต่างหากเมื่อได้รับการร้องขอ ฉันทำเช่นนี้เพราะเกือบทุกคำขอทำให้แบบสอบถามฐานข้อมูล ฉันใช้ไลบรารีเธรดพูลเพื่อลดการสร้าง / ทำลายเธรด คำถามของฉันคืออะไรจุดตัดที่ดีสำหรับเธรด I / O เช่นนี้คืออะไร ฉันรู้ว่ามันเป็นเพียงการประมาณการคร่าวๆ แต่เราจะพูดหลายร้อย? พัน? ฉันจะหาการตัดยอดนี้ได้อย่างไร? แก้ไข: ขอบคุณสำหรับคำตอบของคุณดูเหมือนว่าฉันจะต้องทดสอบมันเพื่อหาเพดานการนับด้ายของฉัน คำถามคือ: ฉันจะรู้ได้อย่างไรว่าฉันไปถึงเพดานนั้นแล้ว? ฉันควรวัดอะไรอย่างแน่นอน

17
การตั้งชื่อเธรดและเธรดพูลของ ExecutorService
สมมติว่าฉันมีแอปพลิเคชั่นที่ใช้ Executorเฟรมเวิร์ก Executors.newSingleThreadExecutor().submit(new Runnable(){ @Override public void run(){ // do stuff } } เมื่อฉันเรียกใช้แอปพลิเคชันนี้ในดีบักเกอร์เธรดจะถูกสร้างขึ้นด้วยชื่อ (ค่าเริ่มต้น) ต่อไปนี้: Thread[pool-1-thread-1]ไปนี้: อย่างที่คุณเห็นนี่มันไม่มีประโยชน์มากนักและเท่าที่ฉันบอกได้Executorเฟรมเวิร์กไม่มีวิธีง่าย ๆ ในการตั้งชื่อเธรดหรือเธรดพูลที่สร้างขึ้น ดังนั้นหนึ่งจะไปเกี่ยวกับการให้ชื่อสำหรับเธรด / thread-pool อย่างไร Thread[FooPool-FooThread]ยกตัวอย่างเช่น

14
ExecutorService วิธีรองานทั้งหมดให้เสร็จ
วิธีที่ง่ายที่สุดในการรอให้ภารกิจทั้งหมดExecutorServiceเสร็จสิ้นคืออะไร งานของฉันคือการคำนวณเป็นหลักดังนั้นฉันแค่ต้องการเรียกใช้งานจำนวนมาก - หนึ่งในแต่ละหลัก ตอนนี้การตั้งค่าของฉันมีลักษณะดังนี้: ExecutorService es = Executors.newFixedThreadPool(2); for (DataTable singleTable : uniquePhrases) { es.execute(new ComputeDTask(singleTable)); } try{ es.wait(); } catch (InterruptedException e){ e.printStackTrace(); } ComputeDTaskใช้ runnable เรื่องนี้ดูเหมือนจะดำเนินงานได้อย่างถูกต้อง แต่รหัสเกิดปัญหาในด้วยwait() IllegalMonitorStateExceptionนี่เป็นเรื่องแปลกเพราะฉันเล่นไปด้วยตัวอย่างของเล่นและดูเหมือนว่ามันจะใช้ได้ uniquePhrasesมีองค์ประกอบหลายสิบหลายหมื่น ฉันควรใช้วิธีอื่นหรือไม่? ฉันกำลังมองหาบางอย่างที่ง่ายที่สุด

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

6
จะรับ id เธรดจากเธรดพูลได้อย่างไร
ฉันมีกลุ่มเธรดคงที่ที่ฉันส่งงานให้ (จำกัด5เธรด) ฉันจะทราบได้อย่างไรว่าเธรดหนึ่งใน5เธรดใดดำเนินการกับงานของฉัน (เช่น "เธรด # 3 จาก5กำลังทำงานนี้") ExecutorService taskExecutor = Executors.newFixedThreadPool(5); //in infinite loop: taskExecutor.execute(new MyTask()); .... private class MyTask implements Runnable { public void run() { logger.debug("Thread # XXX is doing this task");//how to get thread id? } }

10
การรวมเธรดใน C ++ 11
คำถามที่เกี่ยวข้อง : เกี่ยวกับ C ++ 11: C ++ 11: std :: เธรดรวม? async (เปิดตัว :: async) ใน C ++ 11 จะทำให้เธรดพูลล้าสมัยเพื่อหลีกเลี่ยงการสร้างเธรดที่มีราคาแพงหรือไม่ เกี่ยวกับ Boost: C ++ เพิ่มเธรดใช้เธรดซ้ำ เพิ่ม :: เธรดและสร้างกลุ่มของพวกเขา! ฉันจะได้รับกลุ่มเธรดเพื่อส่งงานโดยไม่ต้องสร้างและลบซ้ำแล้วซ้ำอีกได้อย่างไร ซึ่งหมายความว่าเธรดแบบถาวรจะซิงโครไนซ์ใหม่โดยไม่ต้องเข้าร่วม ฉันมีรหัสที่มีลักษณะดังนี้: namespace { std::vector<std::thread> workers; int total = 4; int arr[4] = {0}; void each_thread_does(int i) { arr[i] += …

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

1
async (launch :: async) ใน C ++ 11 ทำให้เธรดพูลล้าสมัยเนื่องจากหลีกเลี่ยงการสร้างเธรดที่มีราคาแพงหรือไม่
มันเกี่ยวข้องกับคำถามนี้อย่างหลวม ๆ : std :: thread รวมอยู่ใน C ++ 11 หรือไม่? . แม้ว่าคำถามจะแตกต่างกัน แต่ความตั้งใจก็เหมือนกัน: คำถามที่ 1: การใช้เธรดพูลของคุณเอง (หรือไลบรารีของบุคคลที่สาม) เพื่อหลีกเลี่ยงการสร้างเธรดที่มีราคาแพงหรือไม่ ข้อสรุปในคำถามอื่นคือคุณไม่สามารถพึ่งพาstd::threadการรวมกลุ่มกันได้ (อาจเป็นหรือไม่ก็ได้) อย่างไรก็ตามstd::async(launch::async)ดูเหมือนว่าจะมีโอกาสสูงกว่าที่จะถูกรวมกลุ่ม ไม่คิดว่าจะถูกบังคับโดยมาตรฐาน แต่ IMHO ฉันคาดหวังว่าการใช้งาน C ++ 11 ที่ดีทั้งหมดจะใช้การรวมเธรดหากการสร้างเธรดช้า เฉพาะบนแพลตฟอร์มที่มีราคาไม่แพงในการสร้างเธรดใหม่ฉันคาดหวังว่าพวกเขาจะสร้างเธรดใหม่เสมอ คำถาม 2: นี่เป็นเพียงสิ่งที่ฉันคิด แต่ฉันไม่มีข้อเท็จจริงที่จะพิสูจน์ได้ ฉันอาจจะเข้าใจผิด เป็นการคาดเดาที่มีการศึกษาหรือไม่? สุดท้ายนี้ฉันได้ให้โค้ดตัวอย่างที่แสดงให้เห็นก่อนว่าฉันคิดว่าการสร้างเธรดสามารถแสดงได้อย่างไรasync(launch::async): ตัวอย่างที่ 1: thread t([]{ f(); }); // ... t.join(); กลายเป็น auto future …

11
การใช้ ThreadPool.QueueUserWorkItem ใน ASP.NET ในสถานการณ์ที่มีปริมาณการใช้งานสูง
ฉันรู้สึกประทับใจเสมอที่การใช้ ThreadPool สำหรับงานพื้นหลังระยะสั้น (สมมติว่าไม่สำคัญ) ถือเป็นแนวทางปฏิบัติที่ดีที่สุดแม้ใน ASP.NET แต่แล้วฉันก็เจอบทความนี้ซึ่งดูเหมือนจะแนะนำเป็นอย่างอื่น - อาร์กิวเมนต์คือคุณควรออกจาก ThreadPool เพื่อจัดการกับคำขอที่เกี่ยวข้องกับ ASP.NET นี่คือวิธีที่ฉันทำงานแบบอะซิงโครนัสขนาดเล็กจนถึงตอนนี้: ThreadPool.QueueUserWorkItem(s => PostLog(logEvent)) และบทความนี้แนะนำให้สร้างเธรดอย่างชัดเจนแทนโดยคล้ายกับ: new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start() วิธีแรกมีข้อได้เปรียบในการจัดการและกำหนดขอบเขต แต่มีความเป็นไปได้ (ถ้าบทความถูกต้อง) ว่างานเบื้องหลังจะแย่งเธรดด้วยตัวจัดการคำขอ ASP.NET วิธีที่สองทำให้ ThreadPool เป็นอิสระ แต่ต้องเสียค่าใช้จ่ายในการไม่ถูกผูกมัดและอาจใช้ทรัพยากรมากเกินไป คำถามของฉันคือคำแนะนำในบทความถูกต้องหรือไม่? หากไซต์ของคุณได้รับการเข้าชมมากจน ThreadPool ของคุณเริ่มเต็มแล้วจะเป็นการดีกว่าที่จะออกนอกวงหรือ ThreadPool แบบเต็มจะบ่งบอกว่าคุณกำลังใช้ทรัพยากรถึงขีด จำกัด อย่างไรก็ตามในกรณีนี้คุณ ไม่ควรพยายามเริ่มต้นกระทู้ของคุณเอง? คำชี้แจง: ฉันแค่ถามในขอบเขตของงานอะซิงโครนัสขนาดเล็กที่ไม่สำคัญ (เช่นการบันทึกจากระยะไกล) ไม่ใช่งานราคาแพงที่ต้องใช้กระบวนการแยกต่างหาก (ในกรณีนี้ฉันยอมรับว่าคุณจะต้องมีโซลูชันที่มีประสิทธิภาพมากขึ้น)

3
FixedThreadPool vs CachedThreadPool: ความชั่วร้ายน้อยกว่าสองอย่าง
ฉันมีโปรแกรมที่สร้างเธรด (~ 5-150) ซึ่งทำงานได้หลายอย่าง ในขั้นต้นฉันใช้ a FixedThreadPoolเพราะคำถามที่คล้ายกันนี้แนะนำว่าเหมาะสำหรับงานที่มีชีวิตอยู่นานกว่าและด้วยความรู้ที่ จำกัด มากเกี่ยวกับมัลติเธรดฉันจึงคิดว่าอายุการใช้งานเฉลี่ยของเธรด (หลายนาที) " มีอายุยืนยาว " อย่างไรก็ตามฉันเพิ่งเพิ่มความสามารถในการสร้างเธรดเพิ่มเติมและการทำเช่นนั้นทำให้ฉันอยู่เหนือขีด จำกัด เธรดที่ฉันตั้งไว้ ในกรณีนี้จะดีกว่าไหมหากเดาและเพิ่มจำนวนเธรดที่ฉันอนุญาตหรือเปลี่ยนเป็นไฟล์CachedThreadPoolเธรดเพื่อให้ฉันไม่มีเธรดที่สูญเปล่า ลองใช้ทั้งคู่ในเบื้องต้นดูเหมือนจะไม่มีความแตกต่างดังนั้นฉันจึงมีแนวโน้มที่จะไปด้วยวิธีCachedThreadPoolเดียวที่จะหลีกเลี่ยงของเสีย อย่างไรก็ตามช่วงชีวิตของเธรดหมายความว่าฉันควรเลือกFixedThreadPoolและจัดการกับเธรดที่ไม่ได้ใช้แทนหรือไม่? คำถามนี้ทำให้ดูเหมือนว่าเธรดพิเศษเหล่านั้นจะไม่สูญเปล่า แต่ฉันขอขอบคุณสำหรับคำชี้แจง
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.