Những gì đảm bảo hệ thống điều hành thời gian thực thực sự mềm


17

Tôi nghĩ rằng tôi biết hệ điều hành thời gian thực "cứng" là gì. Nó là một hệ điều hành với một bộ lập lịch cung cấp hợp đồng với lập trình viên ứng dụng. Một ứng dụng cung cấp thời hạn với mỗi yêu cầu phân bổ tài nguyên. Nếu các yêu cầu thời hạn là khả thi , bộ lập lịch đảm bảo rằng mỗi tài nguyên sẽ được phân bổ cho ứng dụng yêu cầu trước thời hạn. Bảo đảm là đủ để cho phép một lập trình viên ứng dụng suy luận về độ trễ tối đa và thông lượng tối thiểu của các yêu cầu cụ thể.

Tất cả các định nghĩa tôi tìm thấy về các hệ thống thời gian thực "mềm" dường như còn trống đối với tôi. Wikipedia nói

tính hữu ích của một kết quả suy giảm sau thời hạn, do đó làm giảm chất lượng dịch vụ của hệ thống.

Uhhhh. Được chứ. Theo tiêu chí đó, Windows 95 là một hệ thống thời gian thực mềm và 3BSD cũng vậy và Linux cũng vậy. Wikipedia không phải là một nguồn tuyệt vời, nhưng vài lần truy cập tiếp theo của Google không tốt hơn nhiều. Ví dụ: http://users.ece.cmu.edu/~koopman/des_s99/real_time/ nói

Trong một hệ thống thời gian thực mềm, một hoạt động xuống cấp trong tải cực đại hiếm khi xảy ra có thể được chấp nhận.

Đó không phải là một hợp đồng, đó là một cách không thích nói gì.

Các ví dụ về bảo lãnh / hợp đồng thời gian thực mềm được cung cấp bởi các hệ điều hành thực là gì?

Tôi đang tìm kiếm câu trả lời của mẫu:

Trong (tên hệ điều hành) nếu lập trình viên làm (những gì lập trình viên cần phải làm) thì hệ điều hành đảm bảo (những gì hệ thống đảm bảo).

Câu trả lời:


22

Bạn đã hiểu đúng và Wikipedia có nhiều thông tin nhất có thể - thời gian thực mềm không phải là một đặc điểm chính thức, đó là một đánh giá giá trị. Một cách khác để nói về thời gian thực, mềm mại, thời gian thực của người Hồi giáo, tôi ước rằng đó là thời gian thực, hay có lẽ chính xác hơn là nó phải là thời gian thực nhưng điều đó quá khó.

Nếu bạn thực sự muốn thực hiện dưới hình thức bảo lãnh, thì đó là sự đảm bảo cho nỗ lực tốt nhất chứ không phải là sự đảm bảo về hiệu suất cụ thể.

Hoặc, để trích dẫn Câu hỏi thường gặp về Erlang (Erlang là ngôn ngữ lập trình ban đầu được thiết kế để sử dụng trong điện thoại):

Thời gian thực mềm có nghĩa là gì?

Những người hoài nghi sẽ nói "về cơ bản không có gì".

(Voi) Nhiều hệ thống viễn thông có yêu cầu ít nghiêm ngặt hơn [so với thời gian thực cứng], ví dụ, họ có thể yêu cầu bảo đảm thống kê dọc theo dòng "tìm kiếm cơ sở dữ liệu mất ít hơn 20ms trong 97% trường hợp". Các hệ thống thời gian thực mềm, như Erlang, cho phép bạn thực hiện loại bảo đảm đó.

Và điều này không cung cấp một định nghĩa hữu ích. Thời gian thực mềm cho thấy một thiết kế được tối ưu hóa cho từng tác vụ riêng lẻ không mất quá một khoảng thời gian nhất định , thay vì tối ưu hóa tổng thời gian dành để thực hiện tất cả các tác vụ. Ví dụ: hệ thống thời gian thực mềm sẽ hoàn thành 99,9% yêu cầu trong 10ms và xử lý 100 yêu cầu mỗi giây, trong đó một người không theo thời gian thực có thể nhắm tới tiến hành 200 yêu cầu mỗi giây nhưng cho phép chặn yêu cầu không thường xuyên 50ms trở lên. Một thời gian thực cứng sẽ đảm bảo một yêu cầu cứ sau 15ms cho dù thế nào đi chăng nữa.

Thời gian thực mềm được sử dụng cho các ứng dụng trong đó thời hạn bị bỏ lỡ có nghĩa là sự xuống cấp của dịch vụ, nhưng không quan trọng về hiệu năng. Đa phương tiện và điện thoại là một số trường hợp sử dụng điển hình. Mỗi khung hình âm thanh hoặc video phải được hiển thị theo thời gian, nếu không nó phải được bỏ qua; nhưng bỏ qua một khung hình không phải là kết thúc của thế giới. Các nhà thiết kế của Erlang có các mục tiêu tương tự về độ tin cậy trong các vấn đề khác: họ nhận thấy rằng việc trao đổi qua điện thoại thỉnh thoảng thực hiện cuộc gọi sẽ tốt hơn, nhưng để chắc chắn rằng toàn bộ cuộc trao đổi sẽ tiếp tục hoạt động có thể, hơn là từng có nguy cơ thất bại thảm hại trong việc cố gắng duy trì kết nối bằng mọi giá.

Ngược lại, một cái gì đó như điều khiển một động cơ đòi hỏi phần mềm không bao giờ bỏ lỡ thời hạn. Điều này có chi phí: hiệu suất tổng thể thường chậm hơn và chỉ có thể đạt được các hành vi tương đối đơn giản. Ở phía bên kia của quang phổ, một ứng dụng crunching số thường chỉ quan tâm đến hiệu suất tổng thể - điều quan trọng là ma trận 1000x1000 được nhân lên nhanh như thế nào, chứ không phải mỗi cột được tính nhanh như thế nào.


@ E.DoumundJensen Tuyên bố của bạn là một sự phóng đại. Câu trả lời của bạn về cơ bản không đồng ý với bài viết trên Wikipedia.
Gilles 'SO- ngừng trở nên xấu xa'

Vâng tôi đồng ý. Nhận xét của tôi được dự định bao gồm một số trang Wikipedia về thời gian thực và phần lớn nội dung đó không được xem xét tốt nhất.
E. Douglas Jensen

Khiếu nại lớn nhất của tôi là mọi người không cho rằng phần mềm thời gian thực cứng (đáp ứng mọi thời hạn) phải được xác minh chính thức cho (nói) hệ thống phanh ô tô - vì vậy cũng phải mềm phần mềm thời gian thực (ví dụ: Với xác suất> 0,9 , ít nhất 89% nhiệm vụ phải không quá 20% chậm trễ) được lý giải và chính thức xác minh. Tất cả các hệ thống chiến đấu quân sự là thời gian thực mềm. Thay vào đó mọi người có suy nghĩ cẩu thả và nói "Que Sera Sera."
E. Douglas Jensen

"Cuộc cách mạng đầu tiên là khi bạn thay đổi suy nghĩ về cách bạn nhìn vào mọi thứ và thấy rằng có thể có một cách khác để nhìn vào nó mà bạn chưa được thể hiện." --Gil Scott-Heron, "Cuộc cách mạng sẽ không được truyền hình"
E. Douglas Jensen

4

Linux với bản vá -rt (thời gian thực) cung cấp một bộ lập lịch cung cấp một sự đảm bảo thú vị mà dường như không bỏ trống. (Mặc dù tôi không rõ về cách bảo đảm có thể được đưa vào sử dụng thực tế.)

SCHED_FIFOChính sách lập lịch trình Linux-rt hoạt động như sau: Người dùng chỉ định mức độ ưu tiên cho mọi quy trình. (Các số ưu tiên cho các quy trình "thời gian thực" là 0-99 và các nicegiá trị Unix truyền thống -20 đến 19 ánh xạ tới mức ưu tiên 100 đến 139. (Vì vậy, "0" là mức ưu tiên "cao nhất" và "139" là "thấp nhất" " sự ưu tiên.)

Đảm bảo là bất cứ lúc nào bộ lập lịch sẽ lên lịch các Ncông việc có thể chạy ưu tiên cao nhất trên Nmáy xử lý. Những nỗi đau lớn đã được thực hiện để tránh các vấn đề đảo ngược ưu tiên bên trong kernel. Khi tiến trình Atrở nên chạy được và nó có mức độ ưu tiên cao hơn một số tiến trình đang chạy khác B, Asẽ ngay lập tức được ưu tiên B.

Lưu ý, mặc dù, không có đảm bảo thời gian nghiêm ngặt được đưa ra. Thời gian thực sự dành cho việc thực hiện quyền ưu tiên về mặt lý thuyết có thể kéo dài tùy ý. Ngoài ra, dường như có một số cách trong đó một công việc ưu tiên thấp có thể bắt đầu một loạt các độ trễ dài. Khi i / o hoàn thành các trình xử lý ngắt cho công việc ưu tiên thấp có thể làm gián đoạn một công việc ưu tiên cao hơn, có thể nói là một dạng đảo ngược ưu tiên.

Vì vậy, bảo đảm giới hạn được cung cấp là: nếu có một quy trình duy nhất có mức ưu tiên cao nhất, bất cứ khi nào có thể chạy được, nó sẽ nhận được tất cả các tài nguyên bộ xử lý mà HĐH có thể cung cấp cho nó một cách thực tế. Nếu bạn có giới hạn trên tốt đối với lượng tài nguyên bộ xử lý được tiêu thụ bởi quy trình ưu tiên cao nhất, bạn có thể tính toán ước tính chính xác hợp lý các tài nguyên sẽ có sẵn cho quy trình ưu tiên cao thứ hai, v.v.

Một bài viết chuyên sâu mô tả bộ lập lịch thời gian thực của Linux là http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .


1
Tôi nghĩ rằng Câu hỏi thường gặp RTLinux cung cấp một đặc tính hữu ích ở đây (họ không sử dụng các tính từ cứng hay mềm ): Thẻ Nhiệm vụ ưu tiên cao nhất muốn CPU luôn nhận được CPU trong một khoảng thời gian cố định sau khi sự kiện đánh thức nhiệm vụ đã diễn ra “.
Gilles 'Somali dừng tà ác'

4

Để định nghĩa "thời gian thực mềm", dễ nhất là so sánh nó với "thời gian thực cứng".

Nói chuyện tình cờ, hầu hết mọi người mặc nhiên có một mô hình tinh thần không chính thức coi thông tin hoặc một sự kiện là "thời gian thực"

• nếu, hoặc đến mức độ, nó biểu hiện cho họ với độ trễ (độ trễ) có thể liên quan đến tiền tệ được nhận biết của nó

• tức là, trong khung thời gian mà thông tin hoặc sự kiện có giá trị chấp nhận được đối với họ.

Có rất nhiều định nghĩa ad hoc khác nhau về "thời gian thực cứng", nhưng trong mô hình tinh thần đó, thời gian thực cứng được biểu thị bằng thuật ngữ "nếu". Cụ thể, giả sử rằng các hành động trong thời gian thực (như nhiệm vụ) có thời hạn hoàn thành, giá trị chấp nhận được của sự kiện mà tất cả các nhiệm vụ hoàn thành được giới hạn trong trường hợp đặc biệt là tất cả các nhiệm vụ đều đáp ứng thời hạn.

Các hệ thống thời gian thực cứng đưa ra các giả định rất mạnh mẽ rằng mọi thứ về ứng dụng và hệ thống và môi trường đều tĩnh và được biết là 'tiên nghiệm, ví dụ: nhiệm vụ nào là thời gian đến, thời gian đến, thời hạn của chúng, mà chúng đã thắng Không có xung đột tài nguyên và tổng thể tiến hóa thời gian của hệ thống. Trong một hệ thống điều khiển máy bay hoặc hệ thống phanh ô tô và nhiều trường hợp khác, những giả định đó thường có thể được thỏa mãn để tất cả các thời hạn sẽ được đáp ứng.

Mô hình tinh thần này có tính tổng quát một cách có chủ ý và rất hữu ích để bao gồm cả thời gian thực cứng và mềm - mềm được cung cấp bởi cụm từ "đến mức đó". Ví dụ: giả sử rằng sự kiện hoàn thành nhiệm vụ có giá trị dưới mức tối ưu nhưng có thể chấp nhận được nếu

  • không quá 10% nhiệm vụ bỏ lỡ thời hạn
  • hoặc không có nhiệm vụ nào quá 20%
  • hoặc độ trễ trung bình của tất cả các nhiệm vụ không quá 15%
  • hoặc độ trễ tối đa trong số tất cả các nhiệm vụ là dưới 10%

Đây là tất cả các ví dụ phổ biến về các trường hợp thời gian thực mềm trong rất nhiều ứng dụng.

Hãy xem xét ứng dụng đơn nhiệm vụ đón con bạn sau giờ học. Điều đó có thể không có thời hạn thực tế, thay vào đó có một số giá trị cho bạn và con bạn dựa trên thời điểm sự kiện đó diễn ra. Quá sớm lãng phí tài nguyên (như thời gian của bạn) và quá muộn có một số giá trị tiêu cực vì con bạn có thể bị bỏ lại một mình và có khả năng gây hại (hoặc ít nhất là bất tiện).

Không giống như trường hợp đặc biệt thời gian thực cứng, thời gian thực mềm chỉ đưa ra các giả định cụ thể cần thiết cho ứng dụng tối thiểu về các nhiệm vụ và hệ thống, và không chắc chắn được dự kiến. Để đón con, bạn phải lái xe đến trường và thời gian để làm điều đó là năng động tùy thuộc vào thời tiết, điều kiện giao thông, v.v. Bạn có thể bị cám dỗ cung cấp quá mức cho hệ thống của bạn (nghĩa là cho phép những gì bạn hy vọng là trường hợp lái xe tồi tệ nhất) nhưng một lần nữa điều này làm lãng phí tài nguyên (thời gian của bạn và chiếm dụng phương tiện gia đình, có thể từ chối sử dụng bởi các thành viên khác trong gia đình).

Ví dụ đó có thể không tốn kém về mặt tài nguyên lãng phí, nhưng hãy xem xét các ví dụ khác. Tất cả các hệ thống chiến đấu quân sự là thời gian thực mềm. Ví dụ, hãy xem xét thực hiện một cuộc tấn công máy bay vào một phương tiện mặt đất thù địch bằng cách sử dụng một tên lửa được dẫn đường với các bản cập nhật cho nó như là cơ động mục tiêu. Sự hài lòng tối đa để hoàn thành các nhiệm vụ cập nhật khóa học đạt được bằng một cuộc tấn công hủy diệt trực tiếp vào mục tiêu. Nhưng một nỗ lực cung cấp quá mức các nguồn lực để đảm bảo chắc chắn về kết quả này thường là quá đắt và thậm chí có thể là không thể. Trong trường hợp này, bạn có thể ít hơn nhưng đủ hài lòng nếu tên lửa tấn công đủ gần mục tiêu để vô hiệu hóa nó.

Rõ ràng các kịch bản chiến đấu có rất nhiều sự không chắc chắn năng động có thể phải được quản lý tài nguyên. Các hệ thống thời gian thực mềm cũng rất phổ biến trong nhiều hệ thống dân sự, như tự động hóa công nghiệp, mặc dù rõ ràng các hệ thống quân sự là những thứ nguy hiểm và cấp bách nhất để đạt được giá trị chấp nhận được.

Chìa khóa của hệ thống thời gian thực là "khả năng dự đoán". Trường hợp thời gian thực cứng chỉ quan tâm đến một trường hợp đặc biệt có thể dự đoán được - tức là, tất cả các nhiệm vụ sẽ đáp ứng thời hạn của chúng và giá trị tối đa có thể sẽ đạt được bởi sự kiện đó. Trường hợp đặc biệt đó được đặt tên là "xác định."

Có một phổ dự đoán; hầu hết các hệ thống thời gian thực (cụ thể là các hệ thống mềm) có khả năng dự đoán không xác định, ví dụ, về thời gian hoàn thành nhiệm vụ và do đó các giá trị thu được từ các sự kiện đó. Nói chung, khả năng dự đoán và do đó có thể được đưa ra gần với điểm cuối xác định khi cần thiết nhưng với giá có thể là không thể hoặc quá đắt (như trong chiến đấu hoặc thậm chí là đón con bạn đi học).

Thời gian thực mềm yêu cầu lựa chọn mô hình xác suất cụ thể theo ứng dụng (không phải mô hình thường xuyên phổ biến) và do đó mô hình dự đoán để suy luận về độ trễ sự kiện và giá trị kết quả.

Tham khảo lại danh sách các sự kiện cung cấp giá trị chấp nhận được ở trên, bây giờ chúng ta có thể thêm các trường hợp không xác định, chẳng hạn như

  • xác suất không có nhiệm vụ nào bỏ lỡ thời hạn hơn 5% là lớn hơn 0,87.

Trong một ứng dụng phòng thủ tên lửa, với thực tế là trong chiến đấu, hành vi phạm tội luôn có lợi thế hơn so với phòng thủ, trong hai kịch bản điện toán thời gian thực này bạn sẽ thích:

  • bởi vì việc tiêu diệt hoàn toàn tất cả các tên lửa thù địch là rất khó xảy ra hoặc không thể, hãy giao tài nguyên phòng thủ của bạn để tối đa hóa khả năng nhiều tên lửa đe dọa nhất (ví dụ, dựa vào mục tiêu của chúng) sẽ bị chặn thành công (số lần đánh chặn gần có thể di chuyển tên lửa thù địch ra khỏi khóa học);

  • phàn nàn rằng đây không phải là vấn đề điện toán thời gian thực vì nó động thay vì tĩnh và các khái niệm và kỹ thuật thời gian thực truyền thống không áp dụng, vì vậy bạn không quan tâm đến việc thực hiện R & D cho thời gian thực mềm.

Mặc dù có những hiểu lầm khác nhau về thời gian thực mềm trong cộng đồng điện toán thời gian thực (nhưng không phải trong các lĩnh vực phi điện toán khác), thời gian thực mềm rất chung chung và mạnh mẽ, và có khả năng rất phức tạp so với thời gian thực cứng.

Để trả lời trực tiếp câu hỏi OP:

  • một hệ thống thời gian thực cứng có thể cung cấp các đảm bảo xác định, thông thường nhất là tất cả các nhiệm vụ sẽ đáp ứng thời hạn, thời gian phản hồi cuộc gọi hệ thống sẽ luôn nhỏ hơn x, v.v ... BẮT ĐẦU VÀ CHỈ NẾU các giả định rất mạnh được thực hiện và đúng tất cả mọi thứ quan trọng là tĩnh và được biết là 'tiên nghiệm (nói chung, các đảm bảo như vậy cho các hệ thống thời gian thực cứng là một vấn đề nghiên cứu mở trừ các trường hợp khá đơn giản)

  • theo một hệ thống thời gian thực mềm không đảm bảo tính xác định, nó nhằm cung cấp tính kịp thời xác suất tốt nhất có thể phân tích và khả năng dự đoán về tính kịp thời có thể khả thi trong các tình huống động hiện tại, theo các tiêu chí cụ thể của ứng dụng. Rõ ràng thời gian thực cứng là một trường hợp đặc biệt đơn giản của thời gian thực mềm. Rõ ràng các đảm bảo không xác định phân tích thời gian thực mềm có thể rất phức tạp để cung cấp, nhưng là bắt buộc trong các trường hợp thời gian thực phổ biến nhất (bao gồm cả những trường hợp quan trọng nhất về an toàn như chiến đấu) vì hầu hết các trường hợp đều không tĩnh.

Tôi có một cuộc thảo luận chi tiết chính xác hơn nhiều về thời gian thực, thời gian thực cứng, thời gian thực mềm, tính dự đoán, tính xác định và các chủ đề liên quan trên trang web của tôi real-time.org .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.