Tại sao bạn sẽ sử dụng màn hình thay vì semaphore?

Tôi hiện đang tham gia khóa học lập trình đồng thời ở trường đại học của tôi và gần đây chúng tôi đã bắt đầu nói về khái niệm màn hình. Mặc dù tôi hiểu sự cần thiết của loại trừ lẫn nhau, tôi không hiểu tại sao tôi sẽ sử dụng màn hình cho điều đó.

Theo tôi hiểu, một màn hình đảm bảo rằng chính xác một hoặc không có quá trình nào nằm trong phần quan trọng mọi lúc. Chúng ta có thể đạt được chính xác điều đó với một semaphore. Hơn nữa, chúng tôi triển khai các màn hình (hoặc ít nhất một khả năng để thực hiện chúng là) với các ngữ nghĩa.

Vậy tại sao tôi lại thực hiện một cái gì đó giống hệt như một semaphore với một semaphore? Tôi nhận được những lợi ích gì?

Chúng gần như có thể hoán đổi cho nhau và cái này có thể được xây dựng từ cái kia. Nó phụ thuộc một phần vào ngôn ngữ được triển khai / ưa thích (ví dụ: Java có các màn hình tích hợp sử dụng từ khóa "đồng bộ hóa"). Tuy nhiên, semaphore được coi là một thực thể "cấp thấp hơn" so với màn hình vì những lý do & sự khác biệt sau:

Cả Màn hình và Semaphores đều được sử dụng cho cùng một mục đích - đồng bộ hóa luồng. Nhưng, màn hình sử dụng đơn giản hơn semaphores vì ​​chúng xử lý tất cả các chi tiết của việc thu thập và phát hành khóa. Một ứng dụng sử dụng semaphores phải giải phóng bất kỳ khóa nào mà một luồng đã có được khi ứng dụng kết thúc - điều này phải được thực hiện bởi chính ứng dụng. Nếu ứng dụng không làm điều này, thì bất kỳ luồng nào khác cần tài nguyên được chia sẻ sẽ không thể tiến hành.

Một điểm khác biệt khi sử dụng semaphores là mọi thói quen truy cập tài nguyên dùng chung phải có được khóa aa một cách rõ ràng trước khi sử dụng tài nguyên. Điều này có thể dễ dàng bị lãng quên khi mã hóa các thói quen xử lý đa luồng. Màn hình, không giống như semaphores, tự động có được các khóa cần thiết. [1]

Xem thêm câu trả lời Stack Overflow được bình chọn cao Semaphore so với Màn hình - có gì khác biệt? với sự tương đồng tuyệt vời / đáng nhớ với nhà vệ sinh công cộng và giá để xe đạp.

Cuối cùng chúng tôi đã thảo luận về lý do tại sao bạn sẽ sử dụng một màn hình thay vì một semaphore trong bài giảng ngày hôm nay.

Về cơ bản, vấn đề này là: Màn hình và semaphore có tính biểu cảm như nhau, có nghĩa là bạn có thể tìm ra giải pháp cho một vấn đề với màn hình trong đó ban đầu sử dụng một semaphore và ngược lại.

Chà, chúng tôi đã biết điều đó, vậy tại sao bạn lại sử dụng màn hình thay vì semaphore?

Sở thích cá nhân. Thông thường, một ứng dụng máy tính để bàn sẽ sử dụng màn hình, để lại ít khả năng mắc lỗi hơn, nhưng, như một sự đánh đổi, có cấu trúc cồng kềnh tương đối. Mặt khác, semaphores thường được sử dụng trong các hệ điều hành, vì chúng là một cấu trúc nhẹ, nhưng để lại nhiều khả năng hơn cho các lỗi.

Tôi đoán chúng ta có thể kết luận rằng đó là một quyết định tình huống hay không bạn cần / muốn sử dụng màn hình hoặc semaphore. Nếu bạn xây dựng một hệ thống thời gian thực, bạn có thể muốn đi với một semaphore, nếu bạn đang xây dựng một chương trình văn phòng, bạn có thể đi cùng với một màn hình.

Hãy xem qua ví dụ: "Cuốn sách nhỏ về sempaphores"của Allen B. Downey. nó nêu và giải quyết rất nhiều vấn đề đồng bộ hóa. Đặc biệt kiểm tra các giải pháp đã được khắc phục, và bạn sẽ thấy rằng semaphores là một cơ chế rất thấp, rất mạnh mẽ nhưng cực kỳ dễ sử dụng, trong đó các lỗi đơn giản có những nhược điểm khủng khiếp (thậm chí còn tồi tệ hơn bởi hoạt động không đồng nhất vốn có của các chương trình đồng thời). Đó là ví dụ dễ quên để thực thi loại trừ lẫn nhau, hoạt động trên semaphore sai, v.v. Màn hình cung cấp các giải pháp đóng gói sẵn cho các trường hợp thường được sử dụng nhất và mang theo hầu hết các lợi thế của lập trình hướng đối tượng (nghĩa là bạn biết cách duy nhất để xử lý các biến do màn hình quản lý là thông qua các hoạt động của nó). Nhược điểm là chúng không thể được bổ sung dễ dàng vào các ngôn ngữ không hướng đối tượng,