Hệ thống V IPC so với POSIX IPC

83
  1. Sự khác biệt giữa System V IPCvà là POSIX IPCgì?
  2. Tại sao chúng ta có hai tiêu chuẩn?
  3. Làm thế nào để quyết định sử dụng các chức năng IPC nào?
posix  ipc  sysv 
— Meghasyam
nguồn
2
Có một lý do mà tôi đã dẫn đến việc tôi chọn hàng đợi tin nhắn sysv trên posix. Khả năng gửi tin nhắn bằng mtype không được hỗ trợ trong hàng đợi tin nhắn posix. Tôi đã viết blog về nó ..
— takladev
Trong cuốn sách có tựa đề Linux Programming Unleashed 2nd Edition của Kurt Wall , trang 382, ​​có viết: System V IPC is well known and commonly used, but the Linux implementation of it is badly broken. Tôi không biết nếu các cải tiến Linux được thực hiện để giải quyết vấn đề đó, nếu ai đó biết, xin vui lòng cho biết. Hôm nay, tôi đang phải đối mặt với sự lựa chọn tương tự cho dù Posix IPC hoặc System V IPC và cách tiếp cận của tôi là tìm hiểu kỹ loại IPC nguyên thủy sẽ được sử dụng vì cái này có lợi thế hơn cái kia. Ví dụ, một tiến trình có thể chết đột ngột và sau đó thì sao?
— eigenfield

Câu trả lời:

105

Cả hai đều có các công cụ cơ bản giống nhau - semaphores, bộ nhớ dùng chung và hàng đợi tin nhắn. Họ cung cấp một giao diện hơi khác với những công cụ đó, nhưng các khái niệm cơ bản là giống nhau. Một điểm khác biệt đáng chú ý là POSIX cung cấp một số tính năng thông báo cho hàng đợi tin nhắn mà Sys V không có. (Xem mq_notify().)

Sys V IPC đã tồn tại lâu hơn và có một vài ý nghĩa thiết thực -

Đầu tiên, POSIX IPC ít được triển khai rộng rãi hơn. Tôi đã viết một trình bao bọc Python cho POSIX IPC và tài liệu của nó liệt kê những gì tôi biết về việc triển khai POSIX IPC trên các nền tảng khác nhau .

Trên tất cả các nền tảng được liệt kê trong tài liệu đó, Sys V IPC được triển khai hoàn toàn AFAIK, trong khi bạn có thể thấy POSIX IPC thì không.

Hàm ý thứ hai về độ tuổi tương đối của chúng là POSIX IPC được thiết kế sau khi Sys V IPC đã được sử dụng một thời gian. Do đó, các nhà thiết kế API POSIX đã có thể học hỏi từ những điểm mạnh và điểm yếu của API Sys V. Do đó, API POSIX đơn giản hơn và dễ sử dụng hơn IMO và tôi khuyên bạn nên sử dụng nó trên API Sys V.

Tôi nên lưu ý rằng tôi chưa bao giờ chạy bất kỳ bài kiểm tra hiệu suất nào để so sánh cả hai. Tôi nghĩ rằng API cũ hơn (Sys V) sẽ có nhiều thời gian hơn để điều chỉnh hiệu suất, nhưng đó chỉ là suy đoán, tất nhiên không thể thay thế cho thử nghiệm trong thế giới thực.

Về lý do tại sao có hai tiêu chuẩn - POSIX đã tạo ra tiêu chuẩn của họ vì họ nghĩ rằng đó là một cải tiến trên tiêu chuẩn Sys V. Nhưng nếu mọi người đồng ý rằng POSIX IPC tốt hơn, thì nhiều chương trình vẫn sử dụng Sys V IPC và sẽ mất nhiều năm để chuyển tất cả chúng sang POSIX IPC. Trong thực tế, sẽ không đáng để nỗ lực vì vậy ngay cả khi tất cả mã mới đều sử dụng POSIX IPC kể từ ngày mai, Sys V IPC sẽ tồn tại trong nhiều năm.

Chúng tôi không thể cho bạn biết bạn nên sử dụng cái nào nếu không biết nhiều hơn về những gì bạn định làm, nhưng câu trả lời bạn có ở đây sẽ cung cấp cho bạn đủ thông tin để tự quyết định.

— Philip Semanchuk
nguồn
2
Có một điểm khác biệt quan trọng mà man-page và các bài báo khác không làm nổi bật được, đó là hàng đợi tin nhắn sysv có khái niệm gửi tin nhắn theo mtype (posix msgq thiếu điều này). Trong một số trường hợp, đây có thể là một yếu tố thiết kế quan trọng và để trích dẫn kinh nghiệm của tôi, nó hóa ra là một điểm dừng trưng bày. Tôi đã viết blog về nó.
— takladev
Sau tài liệu của OpenGroup, SysV IPC là một phần của SUS kể từ Ấn bản 2 và giao diện mới, kể từ ấn bản 7. Thật vậy, một giao diện đã có từ lâu hơn, nhưng cả hai đều là một phần của SUS, vì vậy cả hai đều là một phần của POSIX.
— Hibou57
22
  1. Tôi tin rằng sự khác biệt chính là tất cả POSIX IPC đều an toàn theo luồng, trong khi hầu hết SysV IPC thì KHÔNG [ 1 ].
  2. Vì các cuộc chiến tranh Unix [ 2 ]. Đặc tả UNIX đơn (SUS) [ 3 ], hay còn gọi là POSIX, được tạo ra để chuẩn hóa các giao diện trên các hệ thống dựa trên Unix.
  3. Bạn có thể muốn POSIX. Phụ thuộc hoàn toàn vào yêu cầu của bạn.
— jweyrich
nguồn
10

Hệ thống V IPC cũ hơn và POSIX IPC mới hơn. Tuy nhiên có một số khác biệt đối với một số khía cạnh. Không phải lúc nào Posix cũng tốt hơn Hệ thống V.

  1. Semaphores, hàng đợi và bộ nhớ dùng chung cho Posix có tên chuỗi Ascii, trong khi trong Hệ thống V, chúng được cung cấp với số nguyên.

  2. Semaphores System V cho phép tự động giải phóng nếu quá trình chết (cờ semop SEM_UNDO). Không có điều đó cho Posix.

  3. Trên Linux và FreeBSD có lợi thế lớn về hàng đợi posix, vì trình xử lý do mq_open đưa ra về cơ bản là bộ mô tả tệp có thể được thăm dò / epolled / select / kqueued.

— Madars Vi
nguồn
Do đó, có vẻ như sự lựa chọn phụ thuộc vào loại IPC nguyên thủy sẽ sử dụng. Có một số nơi Posix là tuyệt vời, nhưng cũng có những người khác ở đó Hệ thống V cũng tuyệt vời. Nếu một quy trình chết đột ngột và không có API nào trên thế giới có thể chặn sự kiện đó, thì các nguyên thủy IPC sẽ bị treo lơ lửng hoặc do đó việc phát hiện ra nó. Có nhiều trường hợp sử dụng khác nhau, theo đó Posix là tốt nhất, và sau đó có những trường hợp sử dụng khác trong đó System V xử lý tốt vấn đề.
— eigenfield
-3
  • Systen V và POSIX IPC là hai cách triển khai khác nhau, nhưng có liên quan đến cùng một thứ.

"Unix System V, thường được viết tắt là SysV (và thường được phát âm - mặc dù hiếm khi được viết - là" System Five "), là một trong những phiên bản thương mại đầu tiên của hệ điều hành Unix. Ban đầu nó được phát triển bởi American Telephone & Telegraph (AT&T) và phát hành lần đầu vào năm 1983. "

-Wikipedia

"POSIX hoặc" Giao diện Hệ điều hành Di động [dành cho Unix] "là tên của một nhóm các tiêu chuẩn liên quan được IEEE chỉ định để xác định giao diện lập trình ứng dụng (API)"

-Wikipedia

  • Systm V đã ở đó sớm hơn. POSIX phát triển từ sáng kiến ​​tiêu chuẩn hóa của IEEE.

  • GNU / Linux partiallytương thích với POSIX. Việc sử dụng cái nào phụ thuộc vào hệ điều hành bạn đang sử dụng IPC này. Hầu hết các nhà cung cấp đang hướng tới POSIX.

Lập trình mạng Unix: Interprocess Communications v. 2 của Richard Stevens đưa ra một cái nhìn tốt về cả hai điều này.

Lập trình mạng Unix

— Jestin Joy
nguồn
5
Bạn không thảo luận bất cứ điều gì về Interprocess Communicaton như được đề cập trong các câu hỏi.
— Michael Rice
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 cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.