Thực hiện hoán đổi con trỏ trong hệ thống đa luồng bộ đệm đôi

Question

Khi dữ liệu đệm đôi do chia sẻ giữa các luồng, tôi đã sử dụng hệ thống trong đó một luồng đọc từ một bộ đệm, một luồng đọc từ bộ đệm khác và đọc từ bộ đệm đầu tiên. Vấn đề là, làm thế nào tôi sẽ thực hiện trao đổi con trỏ? Tôi có cần sử dụng một phần quan trọng không? Không có chức năng Interlocked có sẵn mà thực sự sẽ trao đổi các giá trị. Tôi không thể có một chủ đề đọc từ bộ đệm một, sau đó bắt đầu đọc từ bộ đệm hai, ở giữa đọc, đó sẽ là appcrash, ngay cả khi các chủ đề khác không sau đó bắt đầu viết cho nó.

Tôi đang sử dụng native C++ trên Windows trong Visual Studio Ultimate 2010 RC.

Answer 1

Tại sao bạn không thể sử dụng InterlockedExchangePointer?

chỉnh sửa: Ok, tôi nhận được những gì bạn đang nói bây giờ, IEP không thực sự trao đổi 2 con trỏ trực tiếp với nhau vì nó chỉ mất một giá trị duy nhất bằng cách tham chiếu.

Answer 2

Sử dụng các phần quan trọng là cách được chấp nhận để thực hiện. Chỉ cần chia sẻ một đối tượng CRITICAL_SECTION giữa tất cả các chủ đề của bạn và gọi EnterCriticalSection và LeaveCriticalSection trên đối tượng đó xung quanh thao tác con trỏ của bạn/bộ đệm đọc/ghi mã. Cố gắng hoàn thành các phần quan trọng của bạn càng sớm càng tốt, để lại nhiều mã bên ngoài các phần quan trọng nhất có thể.

Thậm chí nếu bạn sử dụng thủ thuật trao đổi liên khóa đôi, bạn vẫn cần một phần quan trọng hoặc một thứ gì đó để đồng bộ hóa chủ đề của bạn, vì vậy cũng có thể sử dụng nó cho mục đích này.

Answer 3

Bạn phải xây dựng chức năng của riêng mình để trao đổi các con trỏ sử dụng phần semaphore hoặc phần quan trọng để kiểm soát nó. Sự bảo vệ tương tự cần phải được thêm vào tất cả người dùng của con trỏ, vì bất kỳ mã nào đọc con trỏ đang được sửa đổi là xấu.

Một cách để quản lý việc này là có tất cả các thao tác logic con trỏ hoạt động dưới sự bảo vệ của khóa.

Answer 4

Hãy xem, ban đầu tôi đã thiết kế các chủ đề để chúng hoàn toàn không đồng bộ và không yêu cầu bất kỳ đồng bộ hóa nào trong các hoạt động thường xuyên của chúng. Nhưng, vì tôi đang thực hiện các hoạt động trên cơ sở từng đối tượng trong một nhóm luồng, nếu một đối tượng đã cho không thể đọc được vì nó hiện đang được đồng bộ hóa, tôi có thể thực hiện một thao tác khác trong khi chờ đợi. Theo một nghĩa nào đó, tôi có thể chờ đợi và vận hành cùng một lúc, vì tôi có rất nhiều chủ đề để đi xung quanh.

Tạo hai phần quan trọng, một cho mỗi chủ đề. Trong khi hiển thị, hãy giữ phần kết xuất. Các chủ đề khác vẫn có thể làm những gì nó thích cho phần crit khác mặc dù. Sử dụng TryEnterCriticalSection và nếu nó được giữ, sau đó trả về false và thêm đối tượng vào danh sách sẽ được hiển thị lại sau. Điều này sẽ cho phép chúng tôi tiếp tục hiển thị ngay cả khi một đối tượng cụ thể hiện đang được cập nhật. Trong khi cập nhật, giữ cả hai phần crit. Trong khi thực hiện logic trò chơi, hãy giữ phần crit logic trò chơi. Nếu nó đã được tổ chức, đó là không có vấn đề, bởi vì chúng tôi có nhiều chủ đề hơn so với bộ vi xử lý thực tế. Vì vậy, nếu thread này bị chặn, thì một thread khác sẽ chỉ sử dụng thời gian CPU và điều này không cần phải được quản lý.

Answer 5

Bạn chưa đề cập đến giới hạn nền tảng Windows, nhưng nếu bạn không cần tương thích với các phiên bản cũ hơn Windows Server 2003 hoặc Vista ở phía máy khách, bạn có thể sử dụng chức năng InterlockedExchange64() để trao đổi Giá trị 64 bit. Bằng cách đóng gói hai con trỏ 32 bit vào một cấu trúc cặp 64 bit, bạn có thể hoán đổi hiệu quả hai con trỏ.

Có các biến thể * Liên khóa thông thường trên đó; InterlockedExchangeAcquire64(), InterlockedCompareExchange64(), v.v ...

Nếu bạn cần chạy trên, nói, XP, tôi sẽ đi cho một phần quan trọng. Khi cơ hội tranh chấp thấp, chúng hoạt động khá tốt.

Answer 6

Điều này nghe có vẻ giống như vấn đề về kiểu người đọc-người viết-mutex đối với tôi.

[... nhưng tôi chủ yếu làm phát triển nhúng để điều này có thể không có ý nghĩa đối với hệ điều hành Windows. Trên thực tế, trong một hệ điều hành nhúng với một bộ lập lịch dựa trên ưu tiên, bạn có thể thực hiện điều này mà không cần bất kỳ cơ chế đồng bộ nào, nếu bạn đảm bảo rằng hoán đổi là nguyên tử và chỉ cho phép chuỗi ưu tiên thấp hơn trao đổi bộ đệm. ]

Giả sử bạn có hai bộ đệm, B1 và ​​B2, và bạn có hai luồng, T1 và T2. OK nếu T1 đang sử dụng B1 trong khi T2 đang sử dụng B2. Bằng cách "sử dụng" tôi có nghĩa là đọc và/hoặc viết bộ đệm. Sau đó, tại một thời điểm, các bộ đệm cần phải trao đổi để T1 đang sử dụng B2 và T2 đang sử dụng B1. Điều bạn phải cẩn thận là trao đổi được thực hiện trong khi không có luồng nào đang truy cập bộ đệm của nó.

Giả sử bạn chỉ sử dụng một mutex đơn giản. T1 có thể có được mutex và sử dụng B1. Nếu T2 muốn sử dụng B2, nó sẽ phải chờ mutex. Khi T1 hoàn thành, T2 sẽ bỏ chặn và thực hiện công việc của mình với B2. Nếu một trong hai luồng (hoặc một số chủ đề của bên thứ ba) muốn trao đổi các bộ đệm, nó cũng sẽ phải thực hiện mutex. Vì vậy, chỉ sử dụng một mutex serializes truy cập vào bộ đệm - không tốt như vậy.

Nó có thể hoạt động tốt hơn nếu bạn sử dụng mutex của trình đọc giả. T1 có thể thu được khóa đọc trên mutex và sử dụng B1. T2 cũng có thể có được một khóa đọc trên mutex và sử dụng B2. Khi một trong những chủ đề đó (hoặc một chủ đề của bên thứ ba) quyết định đã đến lúc trao đổi bộ đệm, nó sẽ phải ghi một khóa trên mutex. Nó sẽ không thể có được ghi-khóa cho đến khi không có thêm khóa đọc. Tại thời điểm đó, nó có thể trao đổi các con trỏ đệm, biết rằng không ai đang sử dụng một trong hai bộ đệm bởi vì khi có một khóa ghi trên mutex, tất cả các nỗ lực để đọc-khóa sẽ chặn.