Thay thế cho hàng đợi trong RTOS

Để liên lạc giữa các tác vụ hoặc để chia sẻ dữ liệu giữa hai tác vụ của RTOS, chúng tôi sử dụng Hàng đợi. Nhưng vấn đề với Hàng đợi là chúng chậm .... Họ sao chép dữ liệu trong Bộ đệm sau đó Xử lý Mutex và sau đó Truyền dữ liệu. Thật khó chịu nếu bạn phải truyền dữ liệu lớn. Một vấn đề khác là nếu cùng một hàng đợi được truy cập bởi nhiều tác vụ. Sau đó, Ảnh trở thành như sau: - Đầu tiên Đợi để có quyền truy cập vào Hàng đợi sau đó Xếp hàng Xử lý Mutex nội bộ sau đó Truyền dữ liệu.

Điều này làm tăng chi phí trên hệ thống. Điều gì có thể là sự thay thế hiệu quả cho hàng đợi?

(Tôi đoán câu hỏi này là Độc lập của RTOS mà chúng tôi sử dụng. Hầu hết các RTOS chỉ xử lý Hàng đợi theo cách này)

Hàng đợi hoạt động theo cách đó bởi vì đó là mô hình giao dịch an toàn luồng cho giao tiếp giữa các tác vụ. Bạn có nguy cơ tham nhũng dữ liệu và / hoặc các vấn đề sở hữu trong bất kỳ chương trình ít nghiêm ngặt hơn.

Bạn đang sao chép dữ liệu vào bộ đệm trong bộ nhớ rồi truyền con trỏ với các thành phần hàng đợi hay cố gắng truyền tất cả dữ liệu trong chính các thành phần hàng đợi? Nếu bạn không chuyển con trỏ thì bạn sẽ tăng hiệu suất làm việc đó thay vì truyền từng byte một lần thông qua các phần tử hàng đợi.

Một cách dễ dàng là đặt một con trỏ tới dữ liệu trên hàng đợi và sử dụng dữ liệu bằng con trỏ.

Lưu ý rằng bạn đang giao dịch an toàn cho hiệu suất theo cách này vì bạn phải đảm bảo rằng:

1. bộ đệm vẫn còn hiệu lực cho đến khi người tiêu dùng đã sử dụng dữ liệu
2. ai đó giải phóng bộ đệm

Nếu bạn không sử dụng bộ nhớ được cấp phát động, bạn không phải phân bổ bộ nhớ, nhưng bạn vẫn phải đảm bảo rằng vùng nhớ không được sử dụng lại trước khi dữ liệu được sử dụng.

Hàng đợi không khóa có thể được triển khai cho trường hợp một nhà sản xuất / một người tiêu dùng và thường bạn có thể kiến ​​trúc phần mềm của mình để giảm thiểu số lượng hàng đợi nhiều nhà sản xuất hoặc nhiều người tiêu dùng.

Một hàng đợi không khóa có thể được xây dựng như vậy: Phân bổ một mảng các phần tử sẽ được truyền đạt, và hai số nguyên, gọi chúng là Head and Tail. Head là một chỉ mục vào mảng, trong đó mục tiếp theo sẽ được thêm vào. Đuôi là một chỉ mục vào mảng, trong đó mục tiếp theo có sẵn để được loại bỏ. Nhiệm vụ của nhà sản xuất đọc H và T để xác định xem có chỗ để thêm một mục hay không; ghi mục vào chỉ mục H, sau đó cập nhật H. Các tác vụ của người tiêu dùng đọc H và T để xác định xem có dữ liệu không, đọc dữ liệu từ chỉ mục T, sau đó cập nhật T. Về cơ bản, đó là bộ đệm vòng được truy cập bởi hai tác vụ và thứ tự các thao tác (chèn, sau đó cập nhật H; xóa, sau đó cập nhật T) đảm bảo rằng dữ liệu không xảy ra.

Nếu bạn gặp tình huống với nhiều nhà sản xuất và một người tiêu dùng, hoặc một nhà sản xuất và nhiều người tiêu dùng, bạn thực sự có một giới hạn tài nguyên thuộc loại nào đó, và không có gì khác ngoài việc sử dụng đồng bộ hóa, vì giới hạn hiệu suất có nhiều khả năng là nhà sản xuất / người tiêu dùng đơn độc hơn một hệ điều hành với cơ chế khóa.

Nhưng nếu bạn có nhiều nhà sản xuất VÀ người tiêu dùng, bạn nên dành thời gian (trong không gian thiết kế) để xem liệu bạn có thể có được một cơ chế giao tiếp phối hợp hơn không; trong trường hợp như thế này, việc tuần tự hóa mọi thứ thông qua một hàng đợi chắc chắn làm cho hiệu quả của hàng đợi là yếu tố quyết định trung tâm của hiệu suất.

Người ta có thể có được hoạt động hiệu quả trong hàng đợi một người tiêu dùng đa nhà sản xuất không khóa nếu chính hàng đợi đó chứa các vật phẩm đủ nhỏ để làm việc với một cửa hàng độc quyền, trao đổi so sánh hoặc tương tự, và người ta có thể sử dụng giá trị dành riêng hoặc giá trị dành riêng cho một vị trí hàng đợi trống. Khi viết vào hàng đợi, người viết thực hiện trao đổi so sánh để cố lưu trữ dữ liệu của mình vào khe trống tiếp theo; nếu thất bại, người viết sẽ thử vị trí sau. Mặc dù hàng đợi duy trì một con trỏ đến vị trí trống tiếp theo, giá trị con trỏ là "lời khuyên". Lưu ý rằng nếu một hệ thống sử dụng trao đổi so sánh thay vì độc quyền tải cửa hàng, có thể cần phải có một 'họ' các giá trị 'khe trống' khác nhau. Mặt khác, nếu giữa thời gian người viết tìm thấy một hàng đợi trống và cố gắng ghi vào đó, một nhà văn khác viết khe và người đọc đọc nó, nhà văn đầu tiên sẽ vô tình đặt dữ liệu của mình vào một nơi mà người đọc sẽ không nhìn thấy nó. Vấn đề này không xảy ra trong các hệ thống sử dụng độc quyền tải cửa hàng, vì độc quyền cửa hàng sẽ phát hiện ra rằng dữ liệu đã được ghi ngay cả khi nó được ghi lại giá trị cũ.

Bạn có thể truy cập hàng đợi hiệu quả hơn bằng cách viết lên trên hàng đợi Thông thường, hầu hết các RTOS đều hỗ trợ thêm vào phía trước hàng đợi mà không yêu cầu phải có mutex. Nhưng hãy chắc chắn rằng bạn sử dụng thêm vào phía trước hàng đợi tối thiểu nhất có thể, nơi bạn chỉ muốn thực hiện dữ liệu nhanh hơn. Thông thường các cấu trúc hàng đợi có giới hạn kích thước tối đa, do đó bạn không thể đặt tất cả dữ liệu vào hàng đợi do đó việc vượt qua con trỏ luôn dễ dàng.

chúc mừng !!

Hàng đợi vốn không chậm. Việc thực hiện chúng có thể được.

Nếu bạn sao chép dữ liệu một cách mù quáng và sử dụng hàng đợi đồng bộ, bạn sẽ thấy một điểm nhấn hiệu suất.

Như các áp phích khác đã chỉ ra, có những lựa chọn thay thế không khóa. Trường hợp một nhà sản xuất / người tiêu dùng duy nhất là đơn giản; cho nhiều nhà sản xuất và người tiêu dùng, các lock-free thuật toán xếp hàng bởi Michael và Scott (đó là những cái tên cuối cùng của họ) là tiêu chuẩn, và được sử dụng làm cơ sở cho Java ConcurrentLinkedQueue .

Có thể tối ưu hóa nhu cầu xếp hàng trong một số trường hợp nhất định, nhưng chúng cung cấp đảm bảo đồng thời thường mang lại lợi ích đơn giản hóa lớn cho các hệ thống bằng cách cho phép bạn tách rời các tác vụ.