RIO_CQ
RIO_CQ typedef 會透過傳送和接收具有 Winsock 已註冊 I/O 延伸模組的要求，指定用於 I/O 完成通知的完成佇列描述元。
typedef struct RIO_CQ_t* RIO_CQ, **PRIO_CQ;
-
RIO_CQ
-
資料類型，指定透過傳送和接收要求用於 I/O 完成通知的完成佇列描述元。
備註
RIO_CQ物件用於 Winsock 已註冊 I/O 延伸模組傳送和接收網路要求的 I/O 完成通知。
當RIO_CQ完成佇列不是空白時，應用程式可以使用RIONotify 函式來要求通知。 應用程式也可以使用RIODequeueCompletion函式，隨時輪詢RIO_CQ完成佇列的狀態。
RIO_CQ物件是使用RIOCreateCompletionQueue函式建立的。 在建立時，應用程式必須指定佇列的大小，以決定可以保留多少完成專案。 當應用程式呼叫 RIOCreateRequestQueue 函式以取得 RIO_RQ 控制碼時，應用程式必須指定傳送完成的 RIO_CQ 控制碼，以及接收完成 的RIO_CQ 控制碼。 當相同的佇列應該用於傳送和接收完成時，這些控制碼可能會相同。 RIOCreateRequestQueue函式也需要未完成的傳送和接收作業數目上限，這些作業會根據相關聯完成佇列或佇列的容量收費。 如果佇列沒有足夠的容量剩餘， 則RIOCreateRequestQueue 呼叫將會失敗， 且 WSAENOBUFS。
建立 RIO_CQ 時，會設定完成佇列的通知行為。
針對使用事件的完成佇列，RIO_NOTIFICATION_COMPLETION結構的Type成員會設定為RIO_EVENT_COMPLETION。 Event.EventHandle成員應該包含WSACreateEvent或CreateEvent函式所建立之事件的控制碼。 若要接收 RIONotify 完成，應用程式應該使用 WSAWaitForMultipleEvents 或類似的等候常式等候指定的事件控制碼。 如果應用程式計畫重設並重複使用事件，應用程式可以藉由將 Event.NotifyReset 成員設定為非零值來降低額外負荷。 這會導致當通知發生時， 由RIONotify 函式 自動重設事件。 這可減輕呼叫 WSAResetEvent 函式的需求，以重設 對RIONotify 函式 呼叫之間的事件。
對於使用 I/O 完成埠的完成佇列，RIO_NOTIFICATION_COMPLETION結構的Type成員會設定為RIO_IOCP_COMPLETION。 Iocp.IocpHandle成員應該包含CreateIoCompletionPort函式所建立之 I/O 完成埠的控制碼。 若要接收 RIONotify 完成，應用程式應該呼叫 GetQueuedCompletionStatus 或 GetQueuedCompletionStatusEx 函式。 應用程式應該為完成佇列提供專用 的 OVERLAPPED 物件，而且也可以使用 Iocp.CompletionKey 成員來區別完成佇列上的 RIONotify 要求與其他 I/O 完成，包括其他完成佇列的 RIONotify 完成。
注意
為了有效率，存取完成佇列 (RIO_CQ結構) ，並要求佇列 (RIO_RQ結構) 不受同步處理基本類型保護。 如果您需要從多個執行緒存取完成或要求佇列，應該以重要區段、精簡讀取器寫入鎖定或類似的機制協調存取。 單一線程存取時不需要此鎖定。 不同的執行緒可以存取個別的要求/完成佇列，而不需要鎖定。 只有在多個執行緒嘗試存取相同的佇列時，才會發生同步處理的需求。 如果多個執行緒在相同的通訊端上傳送和接收，因為傳送和接收作業使用通訊端的要求佇列，則也需要同步處理。
如果多個執行緒嘗試使用RIODequeueCompletion存取相同的RIO_CQ，則必須透過重要區段、精簡讀取器寫入器鎖定或類似的相互排除機制來協調存取。 如果未共用完成佇列，則不需要互斥。
不再需要完成佇列時，應用程式可以使用 RIOCloseCompletionQueue 函式將其關閉。
RIO_CQ typedef 定義于Mswsockdef.h標頭檔中，該標頭檔會自動包含在Mswsock.h標頭檔中。 不應直接使用 Mswsockdef.h 標頭檔。
執行緒安全性
如果多個執行緒嘗試使用RIODequeueCompletion存取相同的RIO_CQ，則必須透過重要區段、精簡讀取器寫入器鎖定或類似的相互排除機制來協調存取。 如果未共用完成佇列，則不需要互斥。
規格需求
| 需求 | 值 |
|---|---|
| 最低支援的用戶端 |
Windows 8 [僅限傳統型應用程式] |
| 最低支援的伺服器 |
Windows Server 2012 [僅限傳統型應用程式] |
| 標頭 |
|
另請參閱
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應