สิ่งที่รับประกันทำให้ระบบปฏิบัติการแบบเรียลไทม์“ นุ่ม” นั้นมีให้


17

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

คำจำกัดความทั้งหมดที่ฉันพบในระบบ "แบบเรียลไทม์" แบบนิ่ม "ดูเหมือนไม่มีความหมายสำหรับฉัน Wikipedia พูดว่า

ประโยชน์ของผลลัพธ์จะลดลงหลังจากวันครบกำหนดดังนั้นจึงลดคุณภาพการบริการของระบบ

uhhhh ตกลง. ตามเกณฑ์ที่ว่า Windows 95 นั้นเป็นระบบแบบเรียลไทม์และ 3BSD ก็เช่นกันและเป็น Linux Wikipedia ไม่ได้เป็นแหล่งที่มาที่ดี แต่ความนิยมของ Google ในอีกไม่กี่ครั้งที่ผ่านมานั้นไม่ค่อยดีนัก ตัวอย่างเช่นhttp://users.ece.cmu.edu/~koopman/des_s99/real_time/พูดว่า

ในระบบแบบเรียลไทม์ที่อ่อนนุ่มสามารถยอมรับการดำเนินการที่ลดลงในการโหลดสูงสุดที่เกิดขึ้นน้อยมาก

นั่นไม่ใช่สัญญานั่นเป็นวิธีแฟนซีที่จะไม่พูดอะไร

ตัวอย่างของการรับประกัน / สัญญาแบบเรียลไทม์นุ่ม ๆ ที่เสนอโดยระบบปฏิบัติการจริงคืออะไร

ฉันกำลังหาคำตอบของแบบฟอร์ม:

ใน (ชื่อระบบปฏิบัติการ) หากโปรแกรมเมอร์ทำ (what-programmer-needs-to-do) ดังนั้นระบบปฏิบัติการรับประกัน (what-the-system-guarantee)

คำตอบ:


22

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

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

หรืออ้างถึงคำถามที่พบบ่อยของErlang (Erlang เป็นภาษาการเขียนโปรแกรมที่ออกแบบมาเพื่อใช้ในระบบโทรศัพท์):

ซอฟท์เรียลไทม์หมายถึงอะไร?

Cynics จะพูดว่า "โดยทั่วไปไม่มีอะไร"

(…) ระบบ telecomm หลายแห่งมีข้อกำหนดที่เข้มงวดน้อยกว่า [ยากกว่าเรียลไทม์] เช่นพวกเขาอาจต้องการการรับประกันทางสถิติตามบรรทัดของ "การค้นหาฐานข้อมูลใช้เวลาน้อยกว่า 20ms ใน 97% ของคดี" ระบบเรียลไทม์ที่อ่อนนุ่มเช่น Erlang ช่วยให้คุณรับประกันได้ว่า

และนี่จะให้คำจำกัดความที่มีประโยชน์ ซอฟท์เรียลไทม์บ่งบอกถึงการออกแบบที่ปรับให้เหมาะกับแต่ละงานโดยใช้เวลาไม่เกินระยะเวลาหนึ่งแทนที่จะไปปรับเวลาทั้งหมดที่ใช้ในการทำงานให้เสร็จสิ้น ตัวอย่างเช่นระบบแบบเรียลไทม์ที่อ่อนนุ่มจะมุ่งมั่นที่จะทำคำขอให้เสร็จสมบูรณ์ 99.9% ใน 10ms และประมวลผล 100 คำร้องขอต่อวินาทีโดยที่ไม่ใช่แบบเรียลไทม์อาจตั้งเป้าที่จะดำเนินการ 200 คำร้องขอต่อวินาที 50ms ขึ้นไป เรียลไทม์ยากจะรับประกันหนึ่งคำขอทุก ๆ 15ms ไม่ว่าอะไรจะเกิดขึ้น

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

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


@ E.DouglasJensen คำพูดของคุณเป็นความพยายามขั้นต้น คำตอบของคุณไม่เห็นด้วยกับบทความ Wikipedia
Gilles 'หยุดชั่วร้าย'

ใช่ฉันเห็นด้วย. ความคิดเห็นของฉันมีจุดประสงค์เพื่อรวมหน้า Wikipedia หลายหน้าเกี่ยวกับเรียลไทม์และเนื้อหาส่วนใหญ่นั้นถือว่าไม่เหมาะสม
E. Douglas Jensen

ข้อร้องเรียนที่ใหญ่ที่สุดของฉันคือผู้คนไม่คิดว่าซอฟต์แวร์แบบเรียลไทม์ (ตรงตามกำหนดเวลาทั้งหมด) จะต้องได้รับการตรวจสอบอย่างเป็นทางการสำหรับ (พูด) ระบบเบรกรถยนต์ - ดังนั้นต้องซอฟท์แวร์ตามเวลาจริงเช่น อย่างน้อย 89% ของงานต้องไม่เกิน 20% ล่าช้า) ให้เหตุผลและยืนยันอย่างเป็นทางการ ระบบการรบของกองทัพทุกระบบนั้นใช้งานได้แบบเรียลไทม์ คนเรามักจะคิดแบบเสแสร้งและพูดว่า "Que Sera Sera"
E. Douglas Jensen

"การปฏิวัติครั้งแรกคือเมื่อคุณเปลี่ยนใจเกี่ยวกับวิธีการมองสิ่งต่าง ๆ และดูว่าอาจมีวิธีอื่นในการมองสิ่งที่คุณไม่ได้ปรากฏ" --Gil Scott-Heron, "การปฏิวัติจะไม่ถูกถ่ายทอดสดทางโทรทัศน์"
E. Douglas Jensen

4

Linux ที่มีแพตช์ -rt (เรียลไทม์) มีตัวกำหนดตารางเวลาที่ให้การรับประกันที่น่าสนใจซึ่งดูเหมือนว่าจะไม่ว่างเปล่า (แม้ว่าฉันจะไม่ชัดเจนว่าจะรับประกันการใช้งานจริงได้อย่างไร)

SCHED_FIFOนโยบายการตั้งเวลาLinux-rt ทำงานดังนี้: ผู้ใช้กำหนดลำดับความสำคัญให้กับทุกกระบวนการ (หมายเลขลำดับความสำคัญสำหรับกระบวนการ "เรียลไทม์" คือ 0-99 และniceค่าUnix ดั้งเดิม-20 ถึง 19 แผนที่เพื่อจัดลำดับความสำคัญ 100 ถึง 139 (ดังนั้น "0" จึงเป็นลำดับความสำคัญ "สูงสุด" และ "139" คือ "ต่ำสุด" "ลำดับความสำคัญ)

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

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

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

ในเชิงลึกบทความอธิบายลินุกซ์แบบ real-time จัดตารางเวลาเป็นhttp://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler


1
ฉันคิดว่าRTLinux FAQให้ลักษณะที่เป็นประโยชน์ที่นี่ (พวกเขาไม่ได้ใช้คำคุณศัพท์ยากหรืออ่อน ):“ งานลำดับความสำคัญสูงสุดที่ต้องการให้ CPU ได้รับ CPU เสมอภายในระยะเวลาคงที่หลังจากเหตุการณ์ที่เกิดขึ้นตื่นขึ้น .”
Gilles 'หยุดความชั่วร้าย'

4

ในการกำหนด "ซอฟต์เรียลไทม์" เป็นการง่ายที่สุดในการเปรียบเทียบกับ "ฮาร์ดเรียลไทม์"

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

•หากหรือเท่าที่เป็นที่ประจักษ์แก่พวกเขาด้วยความล่าช้า (ความล่าช้า) ที่สามารถเกี่ยวข้องกับสกุลเงินที่รับรู้

•เช่นในกรอบเวลาที่ข้อมูลหรือเหตุการณ์มีคุณค่าที่ยอมรับได้

มีคำจำกัดความที่แตกต่างกันมากมายของ "hard-time แบบเรียลไทม์" แต่ในโมเดลจิตนั้น hard-time แบบเรียลไทม์จะแสดงด้วยคำว่า "if" โดยเฉพาะอย่างยิ่งสมมติว่าการกระทำแบบเรียลไทม์ (เช่นงาน) มีกำหนดส่งงานที่เสร็จสมบูรณ์มูลค่าที่น่าพอใจที่ยอมรับได้ของเหตุการณ์ที่งานทั้งหมดเสร็จสมบูรณ์จะถูก จำกัด เฉพาะกรณีพิเศษที่งานทั้งหมดเป็นไปตามกำหนดเวลา

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

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

  • ไม่เกิน 10% ของงานที่พลาดกำหนด
  • หรือไม่มีงานใดที่มีความล่าช้าเกินกว่า 20%
  • หรือความล่าช้าเฉลี่ยของงานทั้งหมดไม่เกิน 15%
  • หรือความล่าช้าสูงสุดในทุกงานน้อยกว่า 10%

นี่คือตัวอย่างทั่วไปของเคสแบบเรียลไทม์ที่มีความนุ่มนวลในแอพพลิเคชั่นมากมาย

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

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

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

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

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

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

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

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

  • ความน่าจะเป็นที่ไม่มีงานใดจะพลาดวันครบกำหนดมากกว่า 5% มากกว่า 0.87

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

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

  • บ่นว่านี่ไม่ใช่ปัญหาการคำนวณแบบเรียลไทม์เพราะมันเป็นแบบไดนามิกแทนที่จะเป็นแบบคงที่และแนวคิดและเทคนิคแบบเรียลไทม์แบบดั้งเดิมไม่ได้นำไปใช้ดังนั้นคุณไม่สนใจที่จะทำ R&D สำหรับซอฟท์แวร์แบบเรียลไทม์

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

หากต้องการตอบคำถาม OP โดยตรง:

  • ระบบเรียลไทม์ที่ยากลำบากสามารถให้การรับรองที่กำหนดได้ - โดยทั่วไปแล้วงานทั้งหมดจะตรงตามกำหนดเวลาของพวกเขาขัดจังหวะหรือเวลาตอบสนองการโทรของระบบจะน้อยกว่า x เป็นต้น - ถ้าและเฉพาะถ้ามีสมมติฐานที่แข็งแกร่งมากและถูกต้อง ทุกสิ่งที่สำคัญคือแบบคงที่และรู้จัก 'นิรนัย (โดยทั่วไปการรับประกันดังกล่าวสำหรับระบบแบบเรียลไทม์ที่ยากคือปัญหาการวิจัยแบบเปิดยกเว้นกรณีที่ค่อนข้างง่าย)

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

ฉันมีรายละเอียดการอภิปรายได้อย่างแม่นยำมากขึ้นเวลาจริงยากเวลาจริงนุ่มแบบ real-time คาดการณ์ชะตาและหัวข้อที่เกี่ยวข้องบนเว็บไซต์ของฉันreal-time.org

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.