Việc sử dụng bộ nhớ heap (malloc / new) có tạo ra một chương trình không xác định không?

Tôi đã bắt đầu phát triển phần mềm cho các hệ thống thời gian thực cách đây vài tháng bằng C cho các ứng dụng không gian và cả cho vi điều khiển với C ++. Có một quy tắc ngón tay cái trong các hệ thống như vậy là không bao giờ được tạo các đối tượng heap (vì vậy không có malloc / new), bởi vì nó làm cho chương trình không xác định . Tôi đã không thể xác minh tính đúng đắn của tuyên bố này khi mọi người nói với tôi điều đó. Vì vậy, Đây có phải là một tuyên bố chính xác?

Sự nhầm lẫn đối với tôi là theo như tôi biết, thuyết xác định có nghĩa là chạy một chương trình hai lần sẽ dẫn đến chính xác, cùng một đường dẫn thực thi. Theo hiểu biết của tôi, đây là một vấn đề với các hệ thống đa luồng, vì chạy cùng một chương trình nhiều lần có thể có các luồng khác nhau chạy theo thứ tự khác nhau mỗi lần.

Trong bối cảnh của các hệ thống thời gian thực, có nhiều điều để xác định hơn là một "đường dẫn thực thi" có thể lặp lại. Một thuộc tính bắt buộc khác là thời gian của các sự kiện chính được giới hạn. Trong các hệ thống thời gian thực cứng, một sự kiện xảy ra ngoài khoảng thời gian cho phép của nó (trước khi bắt đầu khoảng thời gian đó hoặc sau khi kết thúc) thể hiện lỗi hệ thống.

Trong bối cảnh này, việc sử dụng cấp phát bộ nhớ động có thể gây ra tính không xác định, đặc biệt nếu chương trình có các mẫu phân bổ, phân bổ và phân bổ lại khác nhau. Thời gian phân bổ, phân bổ giao dịch và phân bổ lại có thể thay đổi theo thời gian - và do đó làm cho thời gian của toàn bộ hệ thống không thể đoán trước được.

Nhận xét, như đã nói, là không chính xác.

Việc sử dụng trình quản lý đống với hành vi không xác định sẽ tạo ra một chương trình có hành vi không xác định. Nhưng đó là điều hiển nhiên.

Ít rõ ràng hơn một chút là sự tồn tại của những người quản lý đống với hành vi xác định. Có lẽ ví dụ nổi tiếng nhất là bộ phân bổ nhóm. Nó có một mảng N * M byte và một available[]mặt nạ gồm N bit. Để cấp phát, nó kiểm tra mục nhập khả dụng đầu tiên (kiểm tra bit, O (N), giới hạn trên xác định). Để phân bổ, nó thiết lập bit có sẵn (O (1)). malloc(X)sẽ làm tròn X thành giá trị lớn nhất tiếp theo của M để chọn đúng nhóm.

Điều này có thể không hiệu quả lắm, đặc biệt nếu lựa chọn N và M của bạn quá cao. Và nếu bạn chọn quá thấp, chương trình của bạn có thể bị lỗi. Nhưng các giới hạn cho N và M có thể thấp hơn so với một chương trình tương đương không có cấp phát bộ nhớ động.

Không có gì trong tiêu chuẩn C11 hoặc trong n1570 nói rằng điều đó malloclà xác định (hoặc không); và không phải một số tài liệu khác như malloc (3) trên Linux. BTW, nhiều malloctriển khai là phần mềm miễn phí .

Nhưng malloccó thể (và có) không thành công, và hiệu suất của nó không được biết (một cuộc gọi thông thường malloctrên máy tính để bàn của tôi thực tế sẽ mất ít hơn một micro giây, nhưng tôi có thể tưởng tượng ra những tình huống kỳ lạ mà nó có thể mất nhiều hơn, có lẽ là nhiều mili giây khi tải máy tính; đọc về đập ). Và máy tính để bàn Linux của tôi có ASLR (ngẫu nhiên hóa bố cục không gian địa chỉ) nên việc chạy cùng một chương trình hai lần sẽ cung cấp các mallocđịa chỉ khác nhau (trong không gian địa chỉ ảo của quy trình). BTW ở đây là một phương pháp xác định (theo các giả định cụ thể mà bạn cần xây dựng) nhưng thực tế là vô ích malloc.

thuyết xác định nghĩa là chạy một chương trình hai lần sẽ dẫn đến chính xác, cùng một đường dẫn thực thi

Điều này thực tế sai trong hầu hết các hệ thống nhúng, bởi vì môi trường vật lý đang thay đổi; ví dụ, phần mềm điều khiển động cơ tên lửa không thể mong đợi rằng lực đẩy, lực cản, hoặc tốc độ gió, v.v ... là hoàn toàn giống nhau từ lần phóng này đến lần phóng tiếp theo.

^{(Vì vậy, tôi ngạc nhiên khi bạn tin hoặc ước rằng các hệ thống thời gian thực là xác định; chúng không bao giờ có! Có lẽ bạn quan tâm đến WCET , ngày càng khó dự đoán vì bộ nhớ đệm )}

BTW một số hệ thống "thời gian thực" hoặc "nhúng" đang triển khai hệ thống riêng của chúng malloc(hoặc một số biến thể của nó). Các chương trình C ++ có thể có bộ cấp phát -s, có thể sử dụng được bởi các vùng chứa tiêu chuẩn . Xem thêm này và rằng , vv, vv .....

Và các lớp phần mềm nhúng cấp cao (ví dụ như một chiếc ô tô tự hành và phần mềm lập kế hoạch của nó ) chắc chắn đang sử dụng phân bổ đống và thậm chí có thể là các kỹ thuật thu gom rác (một số trong số đó là "thời gian thực"), nhưng thường không được coi là quan trọng về an toàn.

tl; dr: Không phải là cấp phát bộ nhớ động vốn không xác định (như bạn đã định nghĩa nó theo các đường dẫn thực thi giống hệt nhau); nó thường khiến chương trình của bạn không thể đoán trước được . Cụ thể, bạn không thể dự đoán liệu trình phân bổ có thể thất bại khi đối mặt với một chuỗi đầu vào tùy ý hay không.

Bạn có thể có một bộ phân bổ không xác định. Điều này thực sự phổ biến bên ngoài thế giới thời gian thực của bạn, nơi hệ điều hành sử dụng những thứ như ngẫu nhiên hóa bố cục địa chỉ. Tất nhiên, điều đó sẽ làm cho chương trình của bạn không có tính xác định.

Nhưng đó không phải là một trường hợp thú vị, vì vậy hãy giả sử một công cụ phân bổ hoàn toàn xác định: cùng một chuỗi phân bổ và phân bổ sẽ luôn dẫn đến các khối giống nhau ở cùng một vị trí và các phân bổ và phân bổ đó sẽ luôn có thời gian chạy giới hạn.

Bây giờ chương trình của bạn có thể xác định: cùng một tập hợp các đầu vào sẽ dẫn đến chính xác cùng một đường dẫn thực thi.

Vấn đề là nếu bạn đang phân bổ và giải phóng bộ nhớ để đáp ứng các đầu vào, bạn không thể dự đoán liệu một phân bổ có bao giờ thất bại hay không (và thất bại không phải là một tùy chọn).

Đầu tiên, chương trình của bạn có thể bị rò rỉ bộ nhớ. Vì vậy, nếu nó cần chạy vô thời hạn, cuối cùng một phân bổ sẽ không thành công.

Nhưng ngay cả khi bạn có thể chứng minh rằng không có rò rỉ, bạn sẽ cần biết rằng không bao giờ có một chuỗi đầu vào có thể đòi hỏi nhiều bộ nhớ hơn khả dụng.

Nhưng ngay cả khi bạn có thể chứng minh rằng chương trình sẽ không bao giờ cần nhiều bộ nhớ hơn khả dụng, trình cấp phát có thể, tùy thuộc vào trình tự cấp phát và giải phóng, phân mảnh bộ nhớ và do đó cuối cùng không thể tìm thấy một khối liền kề để đáp ứng cấp phát, mặc dù có đủ bộ nhớ trống về tổng thể.

Rất khó để chứng minh rằng không có trình tự đầu vào nào dẫn đến phân mảnh bệnh lý.

Bạn có thể thiết kế trình cấp phát để đảm bảo không có sự phân mảnh (ví dụ: bằng cách cấp phát các khối chỉ có một kích thước), nhưng điều đó đặt ra một hạn chế đáng kể đối với người gọi và có thể làm tăng dung lượng bộ nhớ cần thiết do lãng phí. Và người gọi vẫn phải chứng minh rằng không có rò rỉ và có giới hạn trên tương đối trên tổng bộ nhớ được yêu cầu bất kể trình tự đầu vào là gì. Gánh nặng này rất cao nên việc thiết kế hệ thống đơn giản hơn để nó không sử dụng phân bổ bộ nhớ động.

Đối phó với các hệ thống thời gian thực là chương trình phải đáp ứng nghiêm ngặt các giới hạn tính toán và bộ nhớ nhất định bất kể đường thực thi được thực hiện là gì (có thể vẫn thay đổi đáng kể tùy thuộc vào đầu vào). Vậy việc sử dụng cấp phát bộ nhớ động chung (chẳng hạn như malloc / new) có nghĩa là gì trong bối cảnh này? Điều đó có nghĩa là nhà phát triển tại một số điểm không thể xác định mức tiêu thụ bộ nhớ chính xác và sẽ không thể biết liệu chương trình kết quả có thể đáp ứng các yêu cầu, cả về bộ nhớ và sức mạnh tính toán hay không.

Vâng, đúng rồi. Đối với loại ứng dụng bạn đề cập, mọi thứ có thể xảy ra phải được chỉ định chi tiết. Chương trình phải xử lý tình huống xấu nhất theo đặc điểm kỹ thuật và dành chính xác lượng bộ nhớ đó, không hơn không kém. Tình trạng "chúng tôi không biết chúng tôi nhận được bao nhiêu đầu vào" không tồn tại. Tình huống xấu nhất được chỉ định với các số cố định.

Chương trình của bạn phải có tính xác định theo nghĩa là nó có thể xử lý mọi thứ cho đến trường hợp xấu nhất.

Mục đích chính của heap là cho phép một số ứng dụng không liên quan chia sẻ bộ nhớ RAM, chẳng hạn như trong PC, nơi số lượng chương trình / quy trình / luồng đang chạy là không xác định. Kịch bản này không tồn tại trong hệ thống thời gian thực.

Ngoài ra, heap về bản chất là không xác định, vì các phân đoạn được thêm hoặc bớt theo thời gian.

Thông tin thêm tại đây: https://electronics.stackexchange.com/a/171581/6102

Ngay cả khi trình phân bổ heap của bạn có hành vi lặp lại (cùng một chuỗi phân bổ và các cuộc gọi miễn phí mang lại cùng một chuỗi khối, do đó (hy vọng) cùng một trạng thái heap nội bộ), trạng thái của heap có thể thay đổi đáng kể nếu trình tự các lệnh gọi được thay đổi , có khả năng dẫn đến phân mảnh sẽ gây ra lỗi cấp phát bộ nhớ theo cách không thể đoán trước.

Lý do phân bổ heap bị cấm hoàn toàn trong các hệ thống nhúng, đặc biệt. các hệ thống quan trọng của sứ mệnh như máy bay hoặc tàu vũ trụ hướng dẫn hoặc hệ thống hỗ trợ sự sống không có cách nào để kiểm tra tất cả các biến thể có thể có trong chuỗi các cuộc gọi bất đồng / miễn phí có thể xảy ra để phản ứng với các sự kiện không đồng bộ về bản chất.

Giải pháp là mỗi trình xử lý có một bộ nhớ dành riêng cho mục đích của nó và điều đó không còn quan trọng nữa (ít nhất là về mức độ sử dụng bộ nhớ) theo thứ tự mà các trình xử lý này được gọi.

Vấn đề với việc sử dụng heap trong phần mềm thời gian thực cứng là phân bổ heap có thể không thành công. Bạn làm gì khi hết đống?

Bạn đang nói về các ứng dụng không gian. Bạn có những yêu cầu khá khó khăn. Bạn phải không có khả năng bị rò rỉ bộ nhớ vì vậy ít nhất là không đủ để mã chế độ an toàn chạy. Bạn không được ngã. Bạn không được ném các ngoại lệ không có khối bắt. Bạn có thể không có một hệ điều hành có bộ nhớ được bảo vệ để một ứng dụng bị lỗi về lý thuyết có thể lấy đi mọi thứ.

Bạn có thể không muốn sử dụng heap chút nào. Các lợi ích không lớn hơn chi phí của toàn bộ chương trình.

Không xác định thường có nghĩa là một cái gì đó khác nhưng trong trường hợp này, đọc tốt nhất là họ muốn toàn bộ hành vi của chương trình hoàn toàn có thể dự đoán được.

Giới thiệu RTOS Integrity từ GHS:

https://www.ghs.com/products/rtos/integrity.html

và LynxOS:

http://www.lynx.com/products/real-time-operating-systems/lynxos-178-rtos-for-do-178b-software-certification/

LynxOS và Integrity RTOS là một trong những phần mềm được sử dụng trong các ứng dụng vũ trụ, tên lửa, máy bay, v.v. vì nhiều phần mềm khác không được cơ quan có thẩm quyền phê duyệt hoặc chứng nhận (ví dụ: FAA).

https://www.ghs.com/news/230210r.html

Để đáp ứng các tiêu chí nghiêm ngặt của các ứng dụng không gian, Integrity RTOS thực sự cung cấp xác minh chính thức, tức là, logic đã được chứng minh bằng toán học, rằng phần mềm của họ hoạt động như theo đặc điểm kỹ thuật.

Trong số các tiêu chí này, để trích dẫn từ đây:

https://en.wikipedia.org/wiki/Integrity_(operating_system)

và đây:

Green Hills Integrity Phân bổ bộ nhớ động

có phải đây là:

Tôi không phải là chuyên gia về các phương pháp chính thức, nhưng có lẽ một trong những yêu cầu đối với việc xác minh này là loại bỏ những điểm không chắc chắn về thời gian cần thiết để cấp phát bộ nhớ. Trong RTOS, tất cả các sự kiện đều được lên kế hoạch chính xác cách xa nhau từng mili giây. Và việc cấp phát bộ nhớ động luôn gặp vấn đề về thời gian cần thiết.

Về mặt toán học, bạn thực sự cần chứng minh mọi thứ hoạt động từ những giả định cơ bản nhất về thời gian và dung lượng bộ nhớ.

Và nếu bạn nghĩ đến các lựa chọn thay thế cho bộ nhớ heap: bộ nhớ tĩnh . Địa chỉ là cố định, kích thước được phân bổ là cố định. Vị trí trong bộ nhớ là cố định. Vì vậy, rất dễ dàng để suy luận về mức độ đủ bộ nhớ, độ tin cậy, tính khả dụng, v.v.

Câu trả lời ngắn

Có một số ảnh hưởng đến các giá trị dữ liệu hoặc sự phân bố độ không đảm bảo thống kê của chúng, ví dụ, thiết bị soi cầu kích hoạt cấp một hoặc cấp hai có thể xuất phát từ khoảng thời gian không thể lặp lại mà bạn có thể phải chờ đợi malloc/free.

Khía cạnh tồi tệ nhất là chúng không liên quan đến hiện tượng vật lý với phần cứng mà bằng cách nào đó với trạng thái của bộ nhớ (và lịch sử của nó).

Trong trường hợp đó, mục tiêu của bạn là tạo lại chuỗi sự kiện ban đầu từ dữ liệu bị ảnh hưởng bởi những lỗi đó. Trình tự được tạo lại / đoán cũng sẽ bị ảnh hưởng bởi lỗi. Không phải lúc nào sự lặp lại này cũng sẽ hội tụ về một giải pháp ổn định; nó không được nói rằng nó sẽ là một trong những chính xác; dữ liệu của bạn không còn độc lập nữa ... Bạn có nguy cơ bị đoản mạch logic ...

Câu trả lời dài hơn

Bạn đã tuyên bố "Tôi không thể xác minh tính đúng đắn của tuyên bố này khi mọi người nói với tôi điều đó" .
Tôi sẽ cố gắng cung cấp cho bạn một tình huống / nghiên cứu điển hình hoàn toàn mang tính giả thuyết.

Chúng ta hãy tưởng tượng bạn xử lý CCD hoặc với một số trình kích hoạt scintillator cấp 1 và 2 trên một hệ thống phải tiết kiệm tài nguyên (bạn đang ở trong không gian).
Tỷ lệ mua lại sẽ được thiết lập để cho nền sẽ có mặt tại x%các MAXBINCOUNT.

• Có một vụ nổ, bạn có một số lượng tăng vọt và tràn trong bộ đếm thùng rác.
  Tôi muốn tất cả: bạn chuyển sang tỷ lệ chuyển đổi tối đa và bạn hoàn thành bộ đệm của mình.
  Bạn giải phóng / cấp phát thêm bộ nhớ trong khi bạn hoàn thành bộ đệm bổ sung.
  Bạn sẽ làm gì?

  1. Bạn sẽ giữ nguyên khả năng chống lại nguy cơ tràn (cấp thứ hai sẽ cố gắng đếm đúng thời gian của các gói dữ liệu) nhưng trong trường hợp này, bạn sẽ đánh giá thấp số lượng cho khoảng thời gian đó?
  2. bạn sẽ dừng bộ đếm giới thiệu một lỗ hổng trong chuỗi thời gian ?

  Lưu ý rằng:

  • Chờ đợi phân bổ, bạn sẽ mất đi sự thoáng qua (hoặc ít nhất là sự khởi đầu của nó).
  • Dù bạn làm gì cũng tùy thuộc vào trạng thái bộ nhớ của bạn và nó không thể tái tạo được.

• Bây giờ thay vào đó, tín hiệu có thể thay đổi xung quanh maxbincounttỷ lệ thu nhận tối đa được phép từ phần cứng của bạn và sự kiện kéo dài hơn bình thường.
  Bạn hoàn thành không gian và yêu cầu thêm ... trong khi đó, bạn phải chịu cùng một vấn đề ở trên.
  Số lượng đỉnh tràn và hệ thống đánh giá thấp hoặc lỗ hổng trong chuỗi thời gian?

Hãy để chúng tôi di chuyển cấp độ thứ hai (nó cũng có thể được kích hoạt cấp độ 1).

Từ phần cứng của mình, bạn nhận được nhiều dữ liệu hơn mức bạn có thể lưu trữ hoặc truyền tải.
Bạn phải phân cụm dữ liệu theo thời gian hoặc không gian (2x2, 4x4, ... 16x16 ... 256x256 ... pixel scale ...).

Sự không chắc chắn từ vấn đề trước đó có thể ảnh hưởng đến sự phân bố lỗi .
Có cài đặt CCD mà bạn có các pixel của đường viền với số gần bằng maxbincount(nó phụ thuộc vào "nơi" bạn muốn xem rõ hơn).
Giờ đây, bạn có thể tắm trên CCD của mình hoặc một điểm lớn duy nhất với tổng số lần đếm giống nhau nhưng có độ không đảm bảo thống kê khác (phần được giới thiệu bởi thời gian chờ) ...

Vì vậy, ví dụ khi bạn đang mong đợi một hồ sơ Lorentzian, bạn có thể lấy tích chập của nó với một Gaussian (một Voigt), hoặc nếu thứ hai nó thực sự chiếm ưu thế với một Gaussian bẩn ...

Luôn luôn có một sự đánh đổi. Đó là môi trường chạy của chương trình và các tác vụ mà nó thực hiện sẽ là cơ sở để quyết định xem có nên sử dụng HEAP hay không.

Đối tượng Heap hiệu quả khi bạn muốn chia sẻ dữ liệu giữa nhiều lệnh gọi hàm. Bạn chỉ cần chuyển con trỏ vì heap có thể truy cập được trên toàn cầu. Có những bất lợi là tốt. Một số chức năng có thể giải phóng bộ nhớ này nhưng vẫn còn một số tham chiếu có thể tồn tại ở những nơi khác.

Nếu bộ nhớ heap không được giải phóng sau khi hoàn thành công việc và chương trình tiếp tục phân bổ thêm bộ nhớ, đến một lúc nào đó HEAP sẽ hết bộ nhớ và ảnh hưởng đến đặc tính xác định của chương trình.