2009-07-16 25 views
7

Cảm giác của tôi từ tài liệu Sổ Địa chỉ và sự hiểu biết của tôi về triển khai CoreData cơ bản cho thấy Sổ Địa chỉ phải là chủ đề an toàn và việc truy vấn từ nhiều luồng sẽ không gây ra vấn đề gì. Nhưng tôi gặp khó khăn khi tìm bất kỳ cuộc thảo luận rõ ràng về an toàn luồng trong tài liệu. Điều này đặt ra một vài câu hỏi:Địa chỉ an toàn và hiệu suất của cuốn sách

  • Có an toàn để sử dụng + sharedAddressBook trên nhiều chủ đề cho quyền truy cập chỉ đọc không? Tôi tin rằng câu trả lời là có.
  • Để ghi quyền truy cập trên chủ đề nền, có vẻ như bạn nên sử dụng + addressBook thay thế (và lưu các thay đổi của bạn theo cách thủ công). Tôi có hiểu điều này một cách chính xác không?
  • Có ai đã điều tra tác động hiệu suất của việc thực hiện nhiều truy vấn đồng thời tới Sổ địa chỉ trên nhiều luồng không? Điều này sẽ rất giống với hiệu suất của việc thực hiện nhiều truy vấn CoreData trên nhiều luồng. Ý nghĩa của tôi là tôi sẽ thu được ít bằng cách thực hiện các truy vấn song song vì tôi cho rằng chúng sẽ tuần tự hóa khi chúng đạt đến SQLLite, nhưng tôi không chắc chắn ở đây.

Tôi cần thực hiện hàng tá truy vấn (một số phức tạp) đối với AddressBook và đang thực hiện trên luồng nền bằng NSOperation để tránh chặn giao diện người dùng (hiện tại). Câu hỏi cơ bản của tôi là liệu có nên thiết lập các hoạt động đồng thời tối đa thành một giá trị lớn hơn 1 hay không và liệu có bất kỳ nguy hiểm nào khi làm như vậy nếu ứng dụng cũng có thể ghi vào AddressBook cùng một lúc trên một chuỗi khác không.

+0

Hiện tại, Khung danh bạ (trường hợp không phải lúc nào) sử dụng Dữ liệu cốt lõi là chi tiết triển khai bạn nên bỏ qua và không nhất thiết đảm bảo an toàn luồng. Bạn có thể cung cấp liên kết đến tài liệu nói rằng API danh bạ là chuỗi an toàn không? Tôi không thể tìm thấy chính sách luồng được nêu trong tài liệu. –

+0

Tôi không thể tìm thấy nó. Đó là điểm tôi đã làm trong đoạn đầu tiên. Tôi không thể tìm thấy bất kỳ cuộc thảo luận rõ ràng về luồng với AB trong bất kỳ tài liệu nào. Nhưng giả sử nó không phải là luồng an toàn tạo ra sự phức tạp rộng rãi mà không cần thiết (và tôi không thể tìm thấy tài liệu về cách thực hiện đúng), do đó nâng cao câu hỏi. –

+3

Vắng mặt một bảo đảm cụ thể bởi khuôn khổ mà nó, hoặc một tập con của nó, là an toàn chỉ, bạn phải bi quan và cho rằng nó không phải là bi quan. –

Trả lời

7

Trừ khi API cho biết đó là chủ đề an toàn thì không. Ngay cả khi việc triển khai hiện tại xảy ra là luồng an toàn, nó có thể không nằm trong tương lai. Nói cách khác, không sử dụng AB từ nhiều luồng.

Ngoài ra, điều gì về nó là CoreData dựa làm cho bạn nghĩ rằng nó sẽ là chủ đề an toàn? CoreData sử dụng mô hình giam giữ chủ đề trong đó chỉ an toàn để truy cập một ngữ cảnh trên một chuỗi đơn lẻ, tất cả các đối tượng từ ngữ cảnh phải được truy cập trên cùng một luồng.

Điều đó có nghĩa là sharedAddressBook sẽ không là chủ đề an toàn nếu nó giữ một NSManagedObjectContext xung quanh để sử dụng. Nó sẽ chỉ an toàn nếu AB tạo ra một bối cảnh mới mỗi lần nó cần làm điều gì đó và ngay lập tức hủy bỏ nó, hoặc nếu nó tạo ra một ngữ cảnh cho mỗi luồng và luôn sử dụng ngữ cảnh thích hợp (có thể bằng cách lưu trữ một ref vào nó trong threadDictionary) . Trong cả hai trường hợp, sẽ không an toàn để lưu trữ bất cứ thứ gì như NSManagedObject vì các bối cảnh sẽ bị phá hủy liên tục, nghĩa là mọi ABRecord sẽ phải lưu trữ một NSManagedObjectID để nó có thể tái tạo đối tượng trong ngữ cảnh thích hợp bất cứ khi nào cần.

Rõ ràng tất cả điều đó là có thể, nó có thể là những gì được thực hiện, nhưng nó hầu như không thực hiện rõ ràng.

+1

Tôi biết về các vấn đề về luồng/ngữ cảnh với CoreData, đó là lý do tại sao tôi trỏ đến sự tồn tại của phương thức + addressBook. Nếu nó không cung cấp một bối cảnh riêng biệt, thì nó có thể phục vụ cho mục đích gì? Khớp nối thiếu thread-an toàn, không có cơ chế khóa, không có hướng dẫn về việc liệu mainThread là cần thiết, và sự chậm chạp của hoạt động, câu hỏi cơ bản vẫn còn ra khỏi đó: làm thế nào để viết chính xác cao đáp ứng các ứng dụng yêu cầu nhiều truy vấn AB. –

Các vấn đề liên quan