2009-11-08 32 views
6

Tôi đang tìm một số thư viện C bao gồm bản đồ băm kiểu STM (Software Transactional Memory), nhưng tôi không có may mắn cho đến nay. Nó sẽ là tuyệt vời nếu nó được dựa trên glib/gobject, nhưng nó không phải là rất quan trọng. Nó cũng không cần các giao dịch thích hợp trên nhiều đối tượng - hỗ trợ băm không thay đổi duy nhất là tất cả những gì tôi thực sự cần.Thư viện băm STM cho C (glib?)

Phải có: đọc nhanh không thể đọc được, ghi không khóa với tự động thử lại.

+0

Ý của bạn là STL thay vì STM? –

+1

Tôi nghĩ anh ấy có nghĩa là STM - Phần mềm giao dịch bộ nhớ - vì anh ấy đang tìm kiếm những thứ như ảnh chụp nhanh và tự động thử lại: http://en.wikipedia.org/wiki/Software_transactional_memory Nhưng anh ấy có lẽ nên làm rõ điều đó, vì STM không phải là khu vực rất nổi tiếng. –

+0

Sửa mô tả. Michael nói đúng. – viraptor

Trả lời

4

Wikipedia có danh sách khác nhau STM implementations.

+0

Tôi đã xem qua những thông tin đó. Nhưng chúng rất thấp. Cách tốt nhất để tích hợp có thể là stmmap: http://github.com/skaphan/stmmap. Nhưng tôi đang tìm cái gì đó đã bao gồm việc thực hiện hashmap. Thật không may tôi không thể chắc chắn rằng những gì một số thư viện cấu trúc dữ liệu ngẫu nhiên làm là an toàn để chỉ sử dụng trên đầu trang của thư viện stm ... Tôi muốn một cái gì đó làm việc trên một cấp độ cao hơn. (sẵn sàng cấu trúc dữ liệu + giải pháp stm) – viraptor

3

Vâng, tôi nghĩ (và có một số nghiên cứu) rằng STM hiện tại không nhanh hơn mã không có khóa và dựa trên mutex. Rõ ràng: STM yêu cầu kiểm tra xung đột dữ liệu trực tuyến. Tuy nhiên, việc kiểm tra xung đột như vậy trong phần mềm thuần túy đòi hỏi chi phí đầu tư rất lớn. Hiện tại, chỉ có ROCK processor của Sun hỗ trợ một dạng giới hạn STM (HTM cố gắng tốt nhất với STM) theo phần cứng. Không có CPU x86 nào hỗ trợ TM trong phần cứng. Trong ngắn hạn, STM chỉ là chậm.

Theo ý kiến ​​của tôi, bạn nên sử dụng bảng băm đồng thời. Ví dụ: bạn có thể tìm thấy concurrent_hash_map trong Intel TBB. Đây là liên kết của TBB Manual. Oh, nhưng đó là C + +, không C. Nhưng, tôi tin rằng bạn có thể (mặc dù nó có thể mất công việc quan trọng) dịch C + + - dựa trên bảng băm như vậy để mã C. Intel TBB là mã nguồn mở.

Ngoài ra, tôi cho rằng cấu trúc dữ liệu đồng thời cao (thường được thực hiện như không có khóa) không phải lúc nào cũng hữu ích. Trong một số mô hình khối lượng công việc, việc sử dụng các cấu trúc dữ liệu như vậy là không tốt. Để chắc chắn, tôi khuyên bạn nên viết một điểm chuẩn nhỏ cho hai phiên bản của bảng băm: (1) không khóa và (2) dựa trên khóa. Ngoài ra, xin lưu ý rằng các mẫu tải công việc cho điểm chuẩn vi mô đó phải gần với điểm chuẩn thực. Một ví dụ có thể được tìm thấy trong here.

+1

Tôi biết chúng đôi khi chậm hơn. Nhưng chúng đôi khi cũng dễ dàng hơn trong một giải pháp cụ thể. Tôi có một băm lớn thường được đọc, hiếm khi được viết. Cũng viết mất một thời gian dài và cần một tra cứu đầu tiên. Với một nhóm độc giả và 1 nhà văn, đây là một trường hợp hoàn hảo cho STM. Ngoài ra, bạn KHÔNG cần kiểm tra xung đột trực tuyến. Bạn có thể triển khai nhiều giải pháp kiểu STM theo cách mà người đọc KHÔNG BAO GIỜ chờ đợi và KHÔNG BAO GIỜ chặn (và người viết không bao giờ chờ đợi, mặc dù có thể cần thử lại) chỉ sử dụng CMPXCHG chuẩn. Đối với tôi đó là một đồng bộ hóa mỗi 30 giây -vs- grabbing đọc khóa mỗi 10ms. – viraptor

+0

Tôi hiểu vấn đề của bạn. Tốt hơn nên sử dụng cấu trúc dữ liệu "không khóa" thay vì kiểu STM. STM luôn có nghĩa là kiểm tra xung đột. Còn RCU thì sao? http://en.wikipedia.org/wiki/Read-copy-update – minjang

+0

PS. Tôi biết rằng concurrent_hash_map được cho là "không khóa", nhưng chúng viết: "Vì việc truy cập vào một phần tử có thể chặn các luồng khác, hãy cố rút ngắn tuổi thọ của trình truy cập hoặc const_accessor." Không đủ tốt cho tôi trong trường hợp này. – viraptor