@synchronized() và sự khác biệt của NSLock

Question

Tôi có một khối mã được truy cập thường xuyên và từ luồng chính hoặc một số luồng nền khác. Tôi cần đảm bảo rằng mã này chỉ được xử lý một lần.

Tôi hiện đang sử dụng khối @synchronized(self) { } nhưng tôi không chắc chắn liệu đó có cung cấp sự bảo vệ chính xác hay không. Nó khác với cá thể NSLock như thế nào?

Cuối cùng, bất kỳ ai cũng có thể đề xuất cách tôi có thể bảo vệ phương pháp của mình không? Phương pháp này là trong đại biểu ứng dụng của tôi, và tôi truy cập nó từ chủ đề khác nhau bằng cách gọi:

[[[UIApplication sharedApplication] delegate] myMethod]; 

Rất cám ơn,

Mike

Answer 1

Có một Blog bài tuyệt vời trên blog của Google Mac về hoạt động bên trong của @synchronized:
http://googlemac.blogspot.com/2006/10/synchronized-swimming.html

tôi hiện đang sử dụng một @synchro khối nized (self) {} nhưng tôi không chắc chắn liệu đó có cung cấp bảo vệ chính xác hay không. Làm thế nào nó khác nhau từ một cá thể NSLock?

Có một số cách để đồng bộ hóa các phần quan trọng (@synchronized, NSLock, OSSpinLock, ...).
Tôi nghĩ rằng @synchronized là cách tiếp cận thuận tiện nhất (and also the slowest).
Here is a good SO answer giải thích sự khác biệt giữa @synchronized và NSLock.

Bạn đang truy cập phương thức của mình thông qua đại diện được chia sẻ (về cơ bản là một singleton). Có thể bạn có thể suy nghĩ lại về thiết kế của mình và tìm ra cách cho phép bạn khóa một đoạn mã nhỏ hơn trong phạm vi myMethod.

Answer 2

Nếu bạn thực sự có điều gì đó mà bạn muốn được xử lý một mục tại một thời điểm, đề xuất của tôi là sử dụng NSOperations và NSOperationQueue nơi bạn đã đặt maxConcurrentOperationCount thành 1. Nếu bạn đảm bảo rằng cách duy nhất khối mã được chia sẻ này được truy cập là thông qua các hoạt động trong hàng đợi này, bạn sẽ bỏ đi với nhu cầu về các khóa đắt tiền.

Điều này có thể yêu cầu sắp xếp lại một chút ứng dụng của bạn, nhưng tôi thấy rằng việc áp dụng điều này trong các ứng dụng của riêng tôi đã dẫn đến hiệu suất tốt hơn và mã sạch hơn.