2010-12-13 36 views
16

Tôi tìm thấy một bài viết năm 2001 về Tiến sĩ Dobbs: volatile - Multithreaded Programmer's Best Friend. Tôi đã luôn luôn tìm thấy 'dễ bay hơi' hơi vô dụng - ít nhất là một vòng loại trên các biến - như truy cập vào các biến được chia sẻ giữa các chủ đề luôn luôn đi qua một số loại lớp thư viện anyway.Hậu quả hoạt động của các hàm thành viên dễ bay hơi

Tuy nhiên, đánh dấu các cá thể lớp và phương pháp, là 'dễ bay hơi' để biểu thị mức độ an toàn của luồng như được trình bày trong bài viết có vẻ rất hấp dẫn.

Để tóm tắt bài báo một cách nhanh chóng, ý tưởng cốt lõi là có thể khai báo một lớp như thế này:

struct SomeObject { 
    void SingleThreadedMethod(); 
    void Method(); 
    void Method() volatile; 
}; 

Và sau đó, trường hợp của lớp, như thế này:

// An object that will only be accessed from a single thread. 
SomeObject singleThreaded; 
// An objecect that will be accessed from multiple threads. 
volatile SomeObject sharedObject; 

sharedObject.SingleThreadedMethod(); //this will be an compile error 
sharedObject.Method(); // will call the volatile overload of Method 
singleThreaded.Method(); // would call the non volatile overload of Method. 

Ý tưởng được rằng các phương thức như "Phương pháp() dễ bay hơi" sẽ được triển khai:

void SomeObject::Method() volatile { 
    enter_critical_section(); 
    const_cast<Method*>(this)->Method(); 
    leave_critical_Section(); 
} 

Rõ ràng là con trỏ thông minh có thể tự động hóa quy trình nguyên tử-lock-and-cast-to-non-volatile - điểm là bộ định mức dễ bay hơi có thể được sử dụng, trong mục đích sử dụng của nó, để đánh dấu các thành viên lớp và các thể hiện để chỉ ra cách chúng sẽ được sử dụng từ nhiều chủ đề và do đó có được trình biên dịch hoặc là nói cho nhà phát triển khi các phương thức đơn luồng (không bay hơi) đang được gọi trên một đối tượng dễ bay hơi, hoặc thậm chí để chọn phiên bản threadsafe tự động.

Câu hỏi của tôi về cách tiếp cận này là: Ý nghĩa hiệu suất của các phương pháp đủ điều kiện 'dễ bay hơi' là gì? Trình biên dịch có buộc phải giả định rằng tất cả các biến được truy cập trong một hàm biến động cần được coi là dễ bay hơi và do đó bị loại trừ khỏi các cơ hội tối ưu hóa? Biến địa phương có bị loại trừ khỏi tối ưu hóa không? Đó có thể là hiệu suất kéo lớn đối với bất kỳ chức năng thành viên đủ điều kiện dễ bay hơi nào nếu có.

+0

"là trình biên dịch buộc phải thừa nhận rằng tất cả các biến truy cập trong một chức năng không ổn định cần phải được đối xử như không ổn định và do đó loại trừ ra khỏi cơ hội tối ưu hóa" Tôi nghĩ như vậy: trình biên dịch được yêu cầu tải từ bộ nhớ con trỏ 'này' mỗi khi đối tượng được chạm vào. Tuy nhiên, các biến cục bộ không bị ảnh hưởng. –

+1

Một số bài viết liên quan: http://stackoverflow.com/questions/2491495, http://stackoverflow.com/questions/2479067 – ronag

+0

Tôi không "yêu thích" nhiều câu hỏi, nhưng tôi yêu thích câu hỏi này. Câu hỏi hay. –

Trả lời

10
  • Không, biến cục bộ sẽ không được giả định là dễ bay hơi theo phương pháp dễ bay hơi, tương tự như cách biến cục bộ không được giả định trong phương pháp const.
  • Tất cả các thành viên của lớp sẽ được coi là dễ bay hơi trong phương pháp dễ bay hơi, tương tự như cách tất cả các thành viên không thể điều khiển được xử lý const theo phương pháp const. Không có tương đương với biến đổi cho dễ bay hơi.
  • this sẽ không phải là một con trỏ dễ bay hơi, vì vậy việc truy cập nó sẽ không tải nó từ bộ nhớ mỗi lần. Tuy nhiên this sẽ là một con trỏ đến biến động, có nghĩa là *this được coi là ổn định
+2

Điều này dường như là giải thích nhất quán về các quy tắc. –

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