Thông tin: Mô tả và hoạt động của OLE luồng mô hình

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:150777
TÓM TẮT
COM các đối tượng có thể được sử dụng trong nhiều chủ đề của một quá trình. Các điều khoản "Single-luồng căn hộ"(STA) và"Multi-threaded căn hộ"(MTA) đang được sử dụng đểtạo một khuôn khổ khái niệm cho mô tả mối quan hệ giữacác đối tượng và chủ đề, các mối quan hệ concurrency trong số các đối tượng, các phương tiệnbằng phương pháp mà các cuộc gọi được chuyển giao cho một đối tượng, và các quy tắc cho đi quagiao diện con trỏ trong số các chủ đề. Các thành phần và khách hàng của họ chọngiữa sau hai căn hộ kiểu hiện nay được hỗ trợ bởi COM:

  1. Đĩa đơn-ren căn hộ mô hình (STA): một hoặc nhiều chủ đề của một quá trình sử dụng COM và các cuộc gọi cho các đối tượng COM được đồng bộ hóa bởi COM. Interfaces là marshaled giữa chủ đề. Một trường hợp thoái hóa đơn-ren mô hình căn hộ chung cư, nơi chỉ một thread trong một quá trình được đưa ra sử dụng COM, là được gọi là mô hình luồng đơn. Trước đó Microsoft thông tin và tài liệu hướng dẫn có đôi khi gọi STA mẫu đơn giản là các "căn hộ kiểu."
  2. Đa luồng căn hộ kiểu (MTA): chủ đề của một hoặc nhiều sử dụng COM và các cuộc gọi cho các đối tượng COM gắn liền với MTA được thực hiện trực tiếp bởi tất cả chủ đề liên quan đến MTA mà không có bất kỳ interposition hệ thống mã giữa người gọi và đối tượng. Vì nhiều khách hàng đồng thời có thể kêu gọi các đối tượng nhiều hơn hoặc ít hơn cùng một lúc (đồng thời nhiều hệ thống), các đối tượng phải đồng bộ hóa tình trạng nội bộ của họ bởi bản thân mình. Giao diện không được marshaled giữa chủ đề. Trước đó Microsoft thông tin và tài liệu đôi khi gọi đến đây mô hình như "miễn phí-ren mẫu."
  3. Cả hai mô hình STA và mô hình MTA có thể được sử dụng trong quá trình. Điều này đôi khi được gọi là một quá trình "trộn-người mẫu".
MTA được giới thiệu trong NT 4.0 và có sẵn trong Windows 95 với DCOM95.Các mô hình STA tồn tại trong Windows NT 3.51 và Windows 95 cũng như NT 4.0và Windows 95 với DCOM95.
THÔNG TIN THÊM

Tổng quan

Các Model threading COM cung cấp cơ chế cho các thành phần mà sử dụngkiến trúc threading khác nhau để làm việc với nhau. Họ cũng cung cấpđồng bộ hóa dịch vụ cho các thành phần đòi hỏi họ. Ví dụ, mộtđối tượng cụ thể có thể được thiết kế để được gọi là chỉ bởi một thread duy nhất vàcó thể không đồng bộ hóa đồng thời các cuộc gọi từ khách hàng. Nếu một đối tượng làđược gọi là đồng thời bởi nhiều chủ đề, nó treo hoặc gây ra lỗi. COMcung cấp cơ chế để đối phó với này khả năng tương tác của luồngkiến trúc.

Các thành phần ngay cả nhận thức được sợi thường cần dịch vụ đồng bộ hóa. ChoVí dụ, các thành phần có một người dùng đồ họa giao diện (GUI), chẳng hạn nhưOLE/điều khiển ActiveX, embeddings hoạt động tại chỗ, và các văn bản ActiveX,cần phải đồng bộ hóa và đăng thường kì trên cuộc gọi COM và cửa sổ tin nhắn.COM cung cấp các dịch vụ đồng bộ hóa để các thành phần này có thểbằng văn bản mà không có đồng bộ hóa phức tạp mã.

Một căn hộ"" có một vài khía cạnh đĩa. Trước tiên, nó là một hợp lýxây dựng cho suy nghĩ về concurrency, chẳng hạn như cách chủ đề liên quan đến mộttập các đối tượng COM. Thứ hai, nó là một tập các quy tắc lập trình viên phải tuân theo đểnhận được hành vi concurrency mà họ mong đợi từ môi trường COM. Cuối cùng,nó là hệ thống cung cấp mã số đó giúp các lập trình viên quản lý chủ đề concurrencyĐối với các đối tượng COM.

Thuật ngữ "căn hộ" xuất phát từ một ẩn dụ trong đó một quá trình được hình thànhnhư một thực thể hoàn toàn rời rạc, ví dụ như một "xây dựng" có nghĩa là chia ramột tập hợp các miền địa phương có liên quan, nhưng khác nhau "cũ" được gọi là "căn hộ chung cư." Một căn hộlà một "hợp lý container" tạo ra một liên kết giữa các đối tượng và,trong một số trường hợp, chủ đề. Chủ đề không phải là căn hộ, mặc dù có thể có mộtđĩa đơn chủ đề một cách hợp lý liên quan đến một căn hộ trong các mô hình STA.Các đối tượng không căn hộ, mặc dù mỗi đối tượng được kết hợp với mộtvà chỉ có một căn hộ. Nhưng các căn hộ là nhiều hơn là chỉ một hợp lýxây dựng; quy tắc của họ mô tả hành vi của hệ thống COM. Nếuquy tắc của các mô hình căn hộ không được theo sau, COM các đối tượng sẽ khônghoạt động đúng.

Thêm chi tiết

Một căn hộ đơn-ren (STA) là một tập các đối tượng COM gắn liền với mộtchủ đề cụ thể. Các đối tượng có liên quan đến căn hộ của đangtạo bởi các chủ đề, hoặc chính xác hơn, đang được đầu tiên tiếp xúc với COMhệ thống (thông thường bởi marshaling) trên các chủ đề. MỘT STA được coi là mộtđặt trong trường hợp một đối tượng hoặc một proxy "cuộc sống." Nếu đối tượng hoặc ủy quyền cần phảiđược truy cập bởi căn hộ khác (trong cùng một hoặc một quá trình khác nhau), của nógiao diện con trỏ phải được marshaled đến căn hộ đó nơi một proxy mới làtạo. Nếu các quy tắc của các mô hình căn hộ được theo sau, không có trực tiếp cuộc gọitừ các chủ đề của quá trình được phép trên đối tượng đó; màsẽ vi phạm các quy tắc mà tất cả các đối tượng trong một căn hộ cho chạy trên mộtchủ đề duy nhất. Các quy tắc tồn tại bởi vì hầu hết mã chạy trong một STA sẽkhông hoạt động đúng nếu chạy trên chủ đề của bổ sung.

Các chủ đề liên quan đến một STA phải gọi CoInitialize hoặcCoInitializeEx (NULL, COINIT_APARTMENTTHREADED) và phải lấy lại vàGửi tin nhắn của cửa sổ cho các đối tượng liên quan đến nhận được gửi đếncác cuộc gọi. COM công văn và đồng bộ hoá các cuộc gọi cho các đối tượng trong một STA bằng cách sử dụngcửa sổ thư, như được diễn tả sau này trong bài viết này.

"Chính STA" là chủ đề mà các cuộc gọi CoInitialize hoặcCoInitializeEx(NULL,COINIT_APARTMENTTHREADED) lần đầu tiên trong một quá trình nhất định.STA chính của một quá trình phải còn lại sống cho đến khi tất cả COM công việc đã hoàn tấtbởi vì có một số đối tượng trong proc luôn luôn tải trong STA chính, nhưmiêu tả sau này trong bài viết này.

Windows NT 4.0 và DCOM95 giới thiệu một loại mới của căn hộ được gọi là cácđa luồng căn hộ (MTA). Một MTA là một tập các đối tượng COM liên kếtvới một tập hợp các chủ đề trong quá trình như vậy là bất kỳ thread có thể gọi bất kỳđối tượng thực hiện trực tiếp mà không cần interposition hệ thống mã.Giao diện con trỏ đến bất kỳ đối tượng trong MTA có thể được thông qua trong số các chủ đềliên kết với MTA mà không cần phải được marshaled. Chủ đề trong cácquá trình gọi CoInitializeEx (NULL, COINIT_MULTITHREADED) được liên kếtvới MTA. Không giống như STA mô tả ở trên, các chủ đề của một MTA khôngcần phải lấy lại và gửi tin nhắn của cửa sổ cho các đối tượng liên quan đếnnhận được cuộc gọi đến. COM không đồng bộ các cuộc gọi cho các đối tượng trong mộtMTA. Các đối tượng trong một MTA phải bảo vệ nhà nước bên trong của họ từ tham nhũng bằngsự tương tác của nhiều đồng thời đề và họ không thể làm cho bất kỳcác giả định về nội dung của Thread-Cục lưu trữ còn lại không đổigiữa các phương pháp khác nhau invocations.

Một quá trình có thể có bất kỳ số nào của STAs, nhưng, nhiều nhất, có thể có một MTA. CácMTA bao gồm một hoặc nhiều chủ đề. STAs có một sợi mỗi. Một chủ đềthuộc về, tối đa, một trong những căn hộ. Các đối tượng thuộc về một và chỉ mộtcăn hộ. Giao diện con trỏ nên luôn luôn được marshaled giữa các căn hộ(mặc dù kết quả của marshaling có thể là một con trỏ trực tiếp thay vì mộtủy quyền). Xem thông tin dưới đây trên CoCreateFreeThreadedMarshaler.

Một quá trình lựa chọn một trong các mô hình threading được cung cấp bởi COM. Một mô hình STAquá trình này có một hoặc nhiều STAs và không có một MTA. Một quá trình mô hình MTAcó một MTA với chủ đề của một hoặc nhiều và không có bất kỳ STAs. Một hỗn hợp-quá trình mô hình có một MTA và bất kỳ số nào của STAs.

Đĩa đơn-ren căn hộ mẫu

Các chủ đề của một STA phải gọi CoInitialize hoặc CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) và phải lấy và gọi khẩn cấp cửa sổ tin nhắnbởi vì COM sử dụng cửa sổ tin nhắn để đồng bộ hóa và gọi khẩn cấp việc phân phốicác cuộc gọi cho một đối tượng trong mô hình này. Xem phần tham khảo bên dưới chobiết thêm thông tin.

Máy chủ mô hình đó STA hỗ trợ:

Trong mô hình STA, các cuộc gọi đến một đối tượng được đồng bộ hóa bởi COM trong cùng mộtcách như cửa sổ tin nhắn gửi đến một cửa sổ được đồng bộ hóa. Các cuộc gọigửi bằng cách sử dụng cửa sổ tin nhắn đến các chủ đề mà tạo ra các đối tượng.Do vậy, chủ đề của đối tượng phải gọi Get/PeekMessage vàDispatchMessage để nhận các cuộc gọi. COM tạo ra một cửa sổ ẩn liên kếtvới mỗi STA. Một cuộc gọi đến một đối tượng từ bên ngoài STA được chuyển giao bởiThời gian chạy COM vào chủ đề của đối tượng bằng cách sử dụng một cửa sổ thư đăng nàyẩn cửa sổ. Khi các chủ đề liên kết với các đối tượng STA truyvà công văn thư, thủ tục cửa sổ cho cửa sổ ẩn,cũng được thực hiện bởi COM, nhận được nó. Thủ tục cửa sổ được sử dụng bởi cácThời gian chạy COM để "treo" sợi chỉ gắn liền với STA vì COMthời gian chạy trên cả hai mặt của cuộc gọi từ thread COM thuộc sở hữu của STAchủ đề. COM runtime (bây giờ chạy trong chủ đề của STA) gọi "lên" thông qua mộtCOM cung cấp khai thành phương pháp giao diện tương ứng của đối tượng.Đường dẫn thực hiện trở lại từ cuộc gọi phương thức đảo ngược "lên" gọi;các cuộc gọi trở lại xuống khai và thời gian chạy COM, đi kiểm soátQuay lại chủ đề runtime COM thông qua một cửa sổ tin nhắn, mà sau đó trở vềthông qua các kênh COM để người gọi gốc.

Khi nhiều khách hàng gọi cho một đối tượng STA, các cuộc gọi sẽ tự độngXếp hàng đợi trong hàng đợi tin nhắn bằng việc chuyển giao các cơ chế kiểm soát được sử dụng trongSTA. Các đối tượng sẽ nhận được một cuộc gọi mỗi khi STA của nó lấy vàcông văn thư. Bởi vì các cuộc gọi được đồng bộ hóa bởi COM ở đâycách, và bởi vì các cuộc gọi luôn được phân phối trên thread duy nhấtliên hệ với các đối tượng STA, triển khai giao diện của đối tượng làmkhông cần phải cung cấp đồng bộ hóa.

LƯU Ý: Các đối tượng có thể được bắt nếu một phương pháp giao diệnthực hiện truy và công văn thư trong khi xử lý một phương phápgọi, gây ra một cuộc gọi để được giao cho đối tượng của cùng một STA. Mộtthông thường trong cách mà điều này xảy ra là nếu một đối tượng STA làm cho một out-going(qua căn hộ/cross-trình) gọi bằng cách sử dụng com Đây là giống hệt nhau để cáccách thức mà trong đó một thủ tục cửa sổ có thể được bắt nếu nó lấy vàcông văn thư trong khi xử lý một tin nhắn. COM không ngăn chặn re-lối vào trên cùng một sợi nhưng ngăn chặn đồng thời thực hiện. Nócũng cung cấp một phương tiện mà liên quan đến COM reentrancy có thể quản lý. Xemtài liệu tham khảo phần dưới đây cho biết thêm thông tin. Không phải là đối tượng re-nhập nếu việc triển khai phương pháp không gọi ra khỏi căn hộ của mình hoặcNếu không truy xuất và gửi tin nhắn.

Khách hàng chịu trách nhiệm trong mô hình STA:

Khách hàng mã chạy trong một quá trình và/hoặc sợi mà sử dụng các mô hình STA phảithống chế giao diện của một đối tượng giữa căn hộ bằng cách sử dụngCoMarshalInterThreadInterfaceInStream và CoGetInterfaceAndReleaseStream.Ví dụ, nếu căn hộ 1 trong các khách hàng có một con trỏ giao diện, vàCăn hộ 2 yêu cầu sử dụng của nó, căn hộ 1 phải nguyên soái giao diệnbằng cách sử dụng CoMarshalInterThreadInterfaceInStream. Đối tượng dòng trở lại bởichức năng này là chủ đề-an toàn và con trỏ giao diện của nó nên được lưu trữ trongmột bộ nhớ trực tiếp biến có thể truy cập bởi 2 căn hộ. Căn hộ 2 phải vượt quagiao diện dòng này để CoGetInterfaceAndReleaseStream để unmarshal cácgiao diện trên đối tượng tiềm ẩn và lấy lại một con trỏ đến một proxyqua đó, nó có thể truy cập các đối tượng.

Căn hộ chính của một quá trình nhất định nên vẫn còn sống cho đến khi khách hàngđã hoàn thành tất cả COM công việc bởi vì một số đối tượng trong proc được nạp trong cácchính-căn hộ. (Thêm chi là chi tiết dưới đây).

Đa luồng căn hộ mẫu

Một MTA là bộ sưu tập của các đối tượng tạo hoặc tiếp xúc của tất cả các chủ đềtrong quá trình đã gọi là CoInitializeEx (NULL, COINIT_MULTITHREADED).

LƯU Ý: Current hiện thực của COM cho phép một sợi mà khôngmột cách rõ ràng khởi tạo COM là một phần của MTA. Một chủ đề mà khônginitialize COM là một phần của MTA chỉ khi nó bắt đầu bằng cách sử dụng COM sau lúcít nhất là một trong những khác thread trong quá trình trước đây gọi làCoInitializeEx (NULL, COINIT_MULTITHREADED). (Thậm chí có thể rằng COMkhởi tạo chính nó có thể có được MTA khi không có chủ đề khách hàng có một cách rõ rànglàm như vậy; Ví dụ, một chủ đề liên quan đến một STA cuộc gọiCoGetClassObject/CoCreateInstance [ví dụ] ngày một CLSID được đánh dấu"ThreadingModel = tự do" và COM ngầm tạo một MTA vào đó cácđối tượng lớp được tải.) Xem thông tin trên luồng mô hìnhkhả năng tương tác dưới đây.

Tuy nhiên, đây là một cấu hình có thể gây ra vấn đề, chẳng hạn nhưtruy cập vào hành vi vi phạm, trong những trường hợp nhất định. Vì vậy, nó là mạnh mẽkhuyến cáo rằng mỗi chủ đề có nhu cầu để làm công việc COM khởi tạo COM bởigọi CoInitializeEx và sau đó, sau khi hoàn tất công việc COM, gọiCoUninitialize. Chi phí không cần "thiết" khởi tạo một MTA là tối thiểu.

Chủ đề của MTA không cần phải lấy lại và gửi thư vì COM nàokhông sử dụng cửa sổ thư trong mô hình này để cung cấp các cuộc gọi đến một đối tượng.

Hệ phục vụ hỗ trợ mô hình MTA:

Trong mô hình MTA, các cuộc gọi đến một đối tượng đang không được đồng bộ bởi COM. Multiplekhách hàng có thể đồng thời gọi cho một đối tượng hỗ trợ mô hình này ngàychủ đề khác nhau, và các đối tượng phải cung cấp đồng bộ hóa trong của nógiao diện/phương pháp triển khai sử dụng đồng bộ hóa các đối tượng nhưcác sự kiện, mutexes, semaphores, vv. MTA các đối tượng có thể nhận được cuộc gọi đồng thờitừ nhiều khách hàng ra quá trình thông qua một hồ bơi của COM tạo chủ đềthuộc về quá trình của đối tượng. MTA các đối tượng có thể nhận được cuộc gọi đồng thờitừ nhiều khách hàng trong quá trình trên nhiều chủ đề liên kết với cácMTA.

Khách hàng chịu trách nhiệm trong mô hình MTA:

Khách hàng mã chạy trong một quá trình và/hoặc sợi mà sử dụng các mô hình MTA nàokhông có để marshal con trỏ giao diện của một đối tượng giữa chính nó vàcác chủ đề khác của MTA. Thay vào đó, một MTA sợi có thể sử dụng một con trỏ giao diệnthu được từ chủ đề MTA khác như một con trỏ bộ nhớ trực tiếp. Khi một khách hàngchủ đề làm cho một cuộc gọi đến một đối tượng ra quá trình, nó đình chỉ cho đến khi cuộc gọiđã hoàn thành. Các cuộc gọi có thể đến nơi trên các đối tượng liên quan đến MTA trong khitất cả các ứng dụng tạo chủ đề liên quan đến MTA đang bị chặn trên ra-các cuộc gọi đi. Trong trường hợp này và nói chung, các cuộc gọi được chuyển giao vàochủ đề được cung cấp bởi COM runtime. Thư bộ lọc (IMessageFilter)không có sẵn để sử dụng trong các mô hình MTA.

Mô hình hỗn hợp phân luồng

Một quá trình có hỗ trợ các mô hình hỗn hợp phân luồng sẽ sử dụng một MTA và mộthoặc thêm STAs. Giao diện con trỏ phải được marshaled giữa tất cả các căn hộnhưng có thể được sử dụng mà không có marshaling trong MTA. Các cuộc gọi cho các đối tượng trong mộtSTA được đồng bộ hóa bởi COM chạy trên chỉ một thread trong khi các cuộc gọi đếnkhông có các đối tượng trong MTA. Tuy nhiên, gọi từ một STA để một MTA bình thườngđi qua hệ thống cung cấp mã và chuyển sang from@MSN.com STA thread một MTAchủ đề trước khi được giao cho các đối tượng.

LƯU Ý: Xem tài liệu SDK vào CoCreateFreeThreadedMarshaler() và cácthảo luận rằng API dưới đây để biết thông tin về trường hợp nơi trực tiếp con trỏcó thể được sử dụng, và làm thế nào một sợi STA có thể gọi trực tiếp vào một đối tượng đầu tiênliên kết với MTA, và ngược lại, từ nhiều căn hộ.

Việc lựa chọn các mô hình Threading

Một thành phần có thể chọn để hỗ trợ các mô hình STA, MTA mẫu, hoặc mộtsự kết hợp của hai bằng cách sử dụng mô hình luồng hỗn hợp. Ví dụ, mộtđối tượng nào rộng rãi I/O có thể chọn để hỗ trợ MTA để cung cấp tối đađáp ứng cho khách hàng bằng cách cho phép giao diện cuộc gọi được thực hiện trong I/Ođộ trễ. Ngoài ra, một vật thể tương tác với người sử dụng hầu nhưluôn luôn chọn để hỗ trợ STA để đồng bộ các cuộc gọi đến COM với của nóGUI hoạt động. Hỗ trợ các mô hình STA là dễ dàng hơn vì COM cung cấpđồng bộ hóa. Hỗ trợ các mô hình MTA là khó khăn hơn vì cácđối tượng phải thực hiện đồng bộ hóa, nhưng để đáp ứng với khách hàng là tốt hơnbởi vì đồng bộ hóa được sử dụng cho phần nhỏ hơn của mã, thay vìcho các cuộc gọi toàn bộ giao diện được cung cấp bởi COM.

Các mô hình STA cũng được sử dụng bởi Microsoft giao dịch Server (MTS, trước đâycó tên mã "Viper"), và vì thế DLL dựa trên vật lập kế hoạch để chạy trong cácMTS môi trường nên sử dụng các mô hình STA. Các đối tượng thực hiện cho MTAmô hình sẽ thường làm việc tốt trong một môi trường MTS. Tuy nhiên, họ sẽ chạyít hiệu quả bởi vì họ sẽ sử dụng chủ đề không cần thiếtđồng bộ hóa nguyên thủy.

Đánh dấu các mô hình hỗ trợ phân luồng của máy chủ trong Proc

Một chủ đề sử dụng mô hình MTA nếu nó gọi CoInitializeEx(NULL,COINIT_MULTITHREADED) hoặc sử dụng COM mà không đang khởi tạo nó. Sử dụng một sợicác mô hình STA nếu nó gọi CoInitialize hoặc CoInitializeEx(NULL,COINIT_APARTMENTTHREADED).

Các API CoInitialize cung cấp kiểm soát căn hộ cho khách hàng mã và chocác đối tượng được đóng gói trong.Emerge, vì thời gian chạy COM khởi động mãcó thể khởi tạo COM trong thời trang mong muốn.

Tuy nhiên, một máy chủ trong-proc (DLL dựa) COM không gọiCoInitialize/CoInitializeEx vì những API sẽ có được gọi là do cácthời gian máy chủ DLL được nạp. Do đó, một máy chủ DLL phải sử dụng cácđăng ký để thông báo cho COM của mô hình threading nó hỗ trợ để các COM có thểđảm bảo rằng hệ thống hoạt động trong một cách đó là tương thích với nó. Mộttên là giá trị của các thành phần CLSID\InprocServer32 phím gọi làThreadingModel được sử dụng cho mục đích này như sau:

  • ThreadingModel không có giá trị: hỗ trợ mô hình luồng đơn.
  • ThreadingModel = căn hộ: hỗ trợ STA mô hình.
  • ThreadingModel = cả hai: hỗ trợ STA và MTA mô hình.
  • ThreadingModel = tự do: hỗ trợ chỉ MTA.
LƯU Ý: ThreadingModel là một giá trị được đặt tên, không một subkey InprocServer32 nhưkhông chính xác trong tài liệu một số phiên bản trước của tài liệu Win32.

Threading mô hình của máy chủ trong proc được thảo luận sau này trong bài viết này. Nếumột máy chủ trong proc cung cấp nhiều loại của các đối tượng (mỗi độc đáo riêng của mìnhCLSID), mỗi loại có thể có một giá trị ThreadingModel khác nhau. Trong kháctừ, các mô hình threading là trên một CLSID, không cho mỗi mã gói/DLL. Tuy nhiên,mục nhập API chỉ cần thiết để "đi" và truy vấn trong proc tất cảmáy chủ (DLLGetClassObject(), DLLCanUnloadNow()) phải là chủ đề an toàn chobất kỳ máy chủ trong proc hỗ trợ nhiều chủ đề (có nghĩa là một ThreadingModelgiá trị của căn hộ, cả, hoặc tự do).

Như đã nói trước đây, ra quá trình máy chủ không đánh dấu mình bằng cách sử dụnggiá trị ThreadingModel. Thay vào đó, họ sử dụng CoInitialize hoặc CoInitializeEx.DLL dựa trên máy chủ có thể mong đợi để chạy ra quá trình bằng cách sử dụng "thay thế"chức năng COM (chẳng hạn như hệ thống cung cấp bà DLLHOST.EXE)chỉ cần làm theo các quy tắc cho DLL dựa trên các máy chủ; không có không có đặc biệtcân nhắc trong trường hợp đó.

Khi khách hàng và đối tượng sử dụng mô hình luồng khác nhau

Tương tác giữa một khách hàng và một đối tượng ra của quá trình là thẳngchuyển tiếp ngay cả khi mô hình threading khác nhau được sử dụng bởi vì khách hàngvà đối tượng đang trong quá trình khác nhau và COM là có liên quan trong qua cuộc gọitừ các khách hàng để đối tượng. Bởi vì COM interposed giữa các khách hàngvà các máy chủ, nó cung cấp mã cho interoperation của các luồngcác mô hình. Ví dụ, nếu một đối tượng STA được gọi là đồng thời bởi nhiềuSTA hoặc MTA khách hàng, COM đồng bộ các cuộc gọi bằng cách đặt tương ứngcửa sổ thư trong hàng đợi tin nhắn của máy chủ. Nhận được các đối tượng STAmột cuộc gọi mỗi khi nó lấy và công văn thư. Kết hợp tất cảmô hình luồng khả năng tương tác cho phép và hoàn toàn được hỗ trợ giữakhách hàng và các đối tượng ra của quá trình.

Tương tác giữa một khách hàng và một đối tượng trong proc sử dụng khác nhauluồng mô hình là phức tạp hơn. Mặc dù các máy chủ là ở-proc, COMphải interpose chính nó giữa khách hàng và đối tượng trong một số trường hợp. ChoVí dụ, một đối tượng trong proc được thiết kế để hỗ trợ các mô hình STA có thể được gọi làđồng thời bởi nhiều chủ đề của một khách hàng. COM không thể cho phép khách hàngchủ đề trực tiếp truy cập vào giao diện của đối tượng vì các đối tượng không phải làđược thiết kế cho truy cập đồng thời. Thay vào đó, COM phải đảm bảo rằng các cuộc gọiđang đồng bộ hóa và thực hiện chỉ bởi các chủ đề liên quan đến STA mà"có" đối tượng. Bất chấp sự phức tạp nhất, tất cả tổ hợpmô hình luồng khả năng tương tác được phép giữa khách hàng và trong proccác đối tượng.

Luồng các mô hình trong Out của quá trình (dựa trên EXE) máy chủ

Sau đây là ba loại ra quá trình máy chủ, mỗi trong số đó có thểđược sử dụng bởi bất kỳ khách hàng COM bất kể của threading mẫu được sử dụng bởi màkhách hàng:

  1. STA Model Server:

    Hệ phục vụ nào COM làm việc trong một hoặc nhiều STAs. Các cuộc gọi đồng bộ hóa bởi COM và cung cấp bởi các chủ đề liên quan đến STA mà các đối tượng được tạo ra. Các cuộc gọi phương thức lớp-nhà máy đang Gửi bởi sợi chỉ gắn liền với STA đăng ký các lớp nhà máy. Các đối tượng và nhà máy sản xuất lớp học không cần phải thực hiện đồng bộ hóa. Tuy nhiên, thực sự phải đồng bộ hóa quyền truy cập vào bất kỳ biến toàn cầu được sử dụng bởi nhiều STAs. Hệ phục vụ phải sử dụng CoMarshalInterThreadInterfaceInStream và CoGetInterfaceAndReleaseStreamđể marshal gợi ý giao diện, có thể từ các máy chủ khác, giữa STAs. Hệ phục vụ tùy chọn có thể thực hiện IMessageFilter trong mỗi STA để kiểm soát các khía cạnh của cuộc gọi giao bởi COM. Một trường hợp thoái hóa là các đĩa đơn phân luồng model rack server mà làm công việc COM trong một STA.
  2. MTA Model Server:

    Hệ phục vụ nào COM làm việc trong một hoặc nhiều chủ đề, tất cả đều thuộc về MTA. Các cuộc gọi không đồng bộ hóa bởi com COM tạo ra một hồ bơi của chủ đề của hệ phục vụ xử lý, và một cuộc gọi khách hàng được phân phối bởi bất kỳ các chủ đề. Chủ đề không phải lấy lại và gửi tin nhắn. Đối tượng và lớp nhà máy phải thực hiện đồng bộ hóa. Hệ phục vụ không cần để marshal con trỏ giao diện giữa các chủ đề.
  3. Hỗn hợp mô hình máy chủ:

    Xem phần trong bài viết này có tiêu đề "mô hình hỗn hợp phân luồng" để biết thêm thông tin.

Luồng các mô hình trong các khách hàng

Có ba loại của khách hàng:

  1. STA mô hình khách hàng:

    Khách hàng nào COM làm việc trong chủ đề liên kết với một hoặc nhiều STAs. Khách hàng phải sử dụng CoMarshalInterThreadInterfaceInStream và CoGetInterfaceAndReleaseStream để thống chế giao diện con trỏ giữa STAs. Một trường hợp thoái hóa là luồng đơn mô hình khách hàng mà không COM làm việc trong một STA. Chủ đề của khách hàng vào một COM cung cấp tin nhắn vòng lặp khi nó làm cho một cuộc gọi đi. Khách hàng có thể sử dụng IMessageFilter để quản lý callbacks và xử lý của cửa sổ thư trong khi chờ đợi Euro cuộc gọi và các vấn đề concurrency.
  2. MTA mô hình khách hàng:

    Khách hàng nào COM làm việc trong một hoặc nhiều chủ đề, tất cả đều thuộc về MTA. Khách hàng không cần để marshal con trỏ giao diện giữa chủ đề của nó. Khách hàng không thể sử dụng IMessageFilter. Chủ đề của khách hàng đình chỉ khi họ làm cho một cuộc gọi COM với một đối tượng ra quá trình và hồ sơ khi trở về cuộc gọi. Các cuộc gọi đến vào COM-tạo và chủ đề của quản lý.
  3. Mô hình hỗn hợp khách hàng:

    Xem phần trong bài viết này có tiêu đề "mô hình hỗn hợp phân luồng" để biết thêm thông tin.

Luồng các mô hình trong trong-proc (DLL dựa) máy chủ:

Có bốn loại của máy chủ trong proc, mỗi trong số đó có thể được sử dụng bởibất kỳ khách hàng COM bất kể của threading mẫu được sử dụng bởi khách hàng đó.Tuy nhiên, các máy chủ trong proc phải cung cấp cho tàn mã cho bất kỳ tuỳ (không-hệ thống định nghĩa) giao diện họ thực hiện nếu chúng để hỗ trợ phân luồngSalon kiểu khả năng cộng tác vì đó thường đòi hỏi rằng nguyên soái COM cácgiao diện giữa các khách hàng căn hộ. Bốn loại là:

  1. Trong proc Server hỗ trợ duy nhất threading ("chính" STA) - không ThreadingModel giá trị:

    Một đối tượng được cung cấp bởi hệ phục vụ này hy vọng sẽ được truy cập bởi cùng một khách hàng STA mà nó được tạo ra. Ngoài ra, máy chủ sẽ tất cả của nó điểm nhập cảnh, chẳng hạn như DllGetClassObject và DllCanUnloadNow, và dữ liệu toàn cầu để được truy cập bởi các chủ đề tương tự (một liên kết với STA chính). Các máy chủ đã tồn tại trước khi sự ra đời của multi- luồng trong COM là trong thể loại này. Các máy chủ không được thiết kế để được truy cập bởi nhiều chủ đề để COM tạo ra tất cả các đối tượng được cung cấp bởi các máy chủ STA chính của quá trình và các cuộc gọi đến các đối tượng đang Gửi bởi các chủ đề liên quan đến chính STA. Khách hàng khác căn hộ được truy cập vào các đối tượng thông qua proxy. Các cuộc gọi từ các các căn hộ khác đến từ các proxy khai trong STA chính (liên- sợi marshaling) và sau đó để đối tượng. Marshaling này cho phép COM để đồng bộ các cuộc gọi đến các đối tượng và các cuộc gọi được giảng dạy bởi STA trong đối tượng được tạo ra. Inter-thread marshaling là tương đối chậm trực tiếp điện thoại vì vậy nó được khuyến khích rằng các máy chủ được viết lại để hỗ trợ nhiều STAs (loại 2).
  2. Trong proc Server có hỗ trợ các mô hình đơn-ren căn hộ (nhiều STAs) - đánh dấu với ThreadingModel = căn hộ:

    Một đối tượng được cung cấp bởi hệ phục vụ này hy vọng sẽ được truy cập bởi cùng một khách hàng STA mà nó được tạo ra. Vì vậy, nó là tương tự như một đối tượng được cung cấp bởi một máy chủ đơn-ren trong-proc. Tuy nhiên, các đối tượng do điều này cung cấp máy chủ có thể được tạo ra trong nhiều STAs của quá trình, Vì vậy các máy chủ phải thiết kế của nó điểm nhập cảnh, chẳng hạn như DllGetClassObject và DllCanUnloadNow, và dữ liệu toàn cầu để sử dụng đa luồng. Cho Ví dụ, nếu hai STAs của một quá trình tạo hai thể hiện của trong proc đối tượng cùng một lúc, DllGetClassObject có thể được gọi là đồng thời bởi cả hai STAs. Tương tự, DllCanUnloadNow phải được bằng văn bản để hệ phục vụ bảo vệ khỏi bị bốc dỡ trong khi mã vẫn đang thực hiện trong các hệ phục vụ.

    Nếu các máy chủ cung cấp chỉ có một thể hiện của nhà máy sản xuất lớp để tạo ra tất cả các đối tượng, lớp nhà máy thực hiện cũng phải được thiết kế để sử dụng đa luồng vì nó được truy cập bởi nhiều khách hàng STAs. Nếu máy chủ tạo ra một trường hợp mới của nhà máy sản xuất lớp mỗi lần DllGetClassObject được gọi là, nhà máy sản xuất lớp học không cần phải Thread an toàn. Tuy nhiên, thực sự phải đồng bộ hóa quyền truy cập vào bất kỳ biến toàn cầu.

    COM các đối tượng tạo bởi nhà máy sản xuất lớp học không phải là sợi-an toàn. Tuy nhiên, truy cập của các biến toàn cầu phải được đồng bộ hóa bởi các thực. Sau khi tạo ra bởi một sợi, các đối tượng luôn luôn truy cập thông qua đó thread và tất cả các cuộc gọi đến các đối tượng được đồng bộ hóa bởi COM. Căn hộ của khách hàng khác nhau hơn STA trong đó đối tượng được tạo ra phải truy cập vào đối tượng thông qua proxy. Những proxy đang tạo ra khi máy sử dụng marshals giao diện giữa các căn hộ của mình.

    Bất kỳ khách hàng tạo ra một đối tượng STA thông qua các nhà máy sản xuất lớp của nó được một trực tiếp con trỏ đến các đối tượng. Điều này là khác nhau hơn so với đĩa đơn-ren các đối tượng trong proc, nơi chỉ STA chính của khách hàng được một trực tiếp con trỏ chỉ tới các đối tượng và tất cả các khác STAs tạo lợi đối tượng truy nhập tới đối tượng thông qua một proxy. Vì inter-thread marshaling chậm so với điện thoại trực tiếp, tốc độ có thể được cải đáng kể thiện bởi thay đổi một máy chủ đơn-ren trong-proc để hỗ trợ nhiều STAs.
  3. Trong proc Server hỗ trợ chỉ MTA - đánh dấu với ThreadingModel = miễn phí:

    Một đối tượng được cung cấp bởi hệ phục vụ này là an toàn cho chỉ MTA. Nó thực hiện đồng bộ hóa riêng của mình và được truy cập bởi nhiều khách hàng chủ đề cùng một lúc. Hệ phục vụ này có thể có hành vi đó là không tương thích với các mô hình STA. (Ví dụ, bằng cách sử dụng của các cửa sổ hàng đợi tin nhắn trong một cách mà phá vỡ các máy bơm thông điệp của một STA.) Ngoài ra, bởi đánh dấu các mô hình threading của đối tượng như là "Tự do," thực của đối tượng nói sau đây: đối tượng này có thể được gọi từ bất kỳ khách hàng chủ đề, nhưng đối tượng này cũng có thể đi giao diện con trỏ trực tiếp (không có marshaling) cho bất kỳ chủ đề mà nó tạo và các chủ đề có thể thực hiện cuộc gọi thông qua các con trỏ. Vì vậy, nếu khách hàng đi một giao diện con trỏ đến một đối tượng khách hàng thực hiện (chẳng hạn như một bồn rửa chén) để đối tượng này, nó có thể chọn để gọi trở lại thông qua con trỏ giao diện này từ bất kỳ thread mà nó tạo ra. Nếu các khách hàng là một STA, một cuộc gọi trực tiếp từ một chủ đề mà là khác nhau từ các sợi đã tạo ra bồn rửa chén đối tượng sẽ lỗi (như chứng minh trong 2 ở trên). Vì thế COM luôn đảm bảo rằng khách hàng trong chủ đề liên quan đến một STA truy cập loại đối tượng trong proc chỉ thông qua một proxy. Ngoài ra, các đối tượng nên không tổng hợp với marshaler miễn phí-ren vì đó cho phép chúng chạy trực tiếp trên chủ đề của STA.
  4. Trong proc Server hỗ trợ mô hình căn hộ và miễn phí-luồng - đánh dấu với ThreadingModel = cả hai:

    Một đối tượng được cung cấp bởi hệ phục vụ này thực hiện đồng bộ hóa riêng của mình và truy cập đồng thời bởi nhiều khách hàng căn hộ. Ngoài ra đối tượng này được tạo ra và được sử dụng trực tiếp, thay vì của thông qua một proxy, trong STAs hoặc MTA một quá trình khách hàng. Bởi vì đối tượng này được sử dụng trực tiếp trong STAs, hệ phục vụ phải nguyên soái giao diện của đối tượng, có thể từ các máy chủ khác giữa các chủ đề như vậy của nó truy cập vào bất kỳ đối tượng một cách phân luồng phù hợp được đảm bảo. Ngoài ra, bằng cách đánh dấu các luồng mô hình của các đối tượng như "Both", //Missing thực của đối tượng nói sau đây: đối tượng này có thể được gọi từ bất kỳ khách hàng chủ đề, nhưng bất kỳ callbacks từ đối tượng này cho khách hàng sẽ được thực hiện chỉ trên căn hộ, trong đó đối tượng đã nhận được con trỏ giao diện đối tượng gọi lại. COM cho phép một đối tượng được tạo ra trực tiếp trong một STA cũng như trong một MTA trình khách hàng.

    Bởi vì bất kỳ căn hộ đó tạo ra một đối tượng như vậy luôn luôn được một trực tiếp con trỏ chứ không phải là một con trỏ ủy quyền, ThreadingModel "Cả hai" các đối tượng cung cấp các cải thiện hiệu suất qua ThreadingModel "Miễn phí" đối tượng khi được tải trong một STA.

    Bởi vì một ThreadingModel "Both" đối tượng cũng được thiết kế để truy cập MTA (nó là hoàn toàn an toàn của sợi trong nội bộ), nó có thể tăng tốc độ hiệu suất bởi tập hợp với marshaler được cung cấp bởi CoCreateFreeThreadedMarshaler. Đối tượng cung cấp hệ thống này tổng hợp trong bất kỳ đối tượng gọi điện thoại và tùy chỉnh nguyên soái hướng con trỏ đến các đối tượng vào tất cả các căn hộ trong tiến trình. Khách hàng trong bất kỳ căn hộ cao cấp, cho dù một STA hoặc MTA, sau đó có thể truy nhập đối tượng trực tiếp thay vì thông qua một proxy. Ví dụ, một khách hàng mẫu STA tạo ra trong proc đối tượng trong STA1 và marshals đối tượng để STA2. Nếu không có đối tượng gì không Tổng hợp với marshaler miễn phí-ren, STA2 thu truy cập vào các đối tượng thông qua một proxy. Nếu có, miễn phí-ren marshaler cung cấp STA2 với một con trỏ trực tiếp đến các đối tượng

    LƯU Ý: Chăm sóc phải được thực hiện khi tập hợp với sự miễn phí-ren marshaler. Ví dụ, giả sử rằng một đối tượng được đánh dấu là ThreadingModel "Cả hai" (và cũng tập hợp với sự miễn phí-ren marshaler) có một thành viên dữ liệu đó là một con trỏ giao diện khác đối tượng mà ThreadingModel là "Căn hộ". Sau đó cho rằng một STA tạo ra các đối tượng đầu tiên và trong sáng tạo, các đối tượng đầu tiên tạo ra các đối tượng thứ hai. Như một quy tắc thảo luận ở trên, các đối tượng đầu tiên là bây giờ đang nắm giữ một con trỏ trực tiếp cho đối tượng thứ hai. Bây giờ cho rằng các STA marshals giao diện con trỏ đối tượng đầu tiên khác căn hộ. Bởi vì các đối tượng đầu tiên tập hợp với miễn phí - ren marshaler, một con trỏ trực tiếp đến các đối tượng đầu tiên được trao cho thứ hai căn hộ. Nếu căn hộ thứ hai sau đó cuộc gọi thông qua con trỏ này, và Nếu cuộc gọi này gây ra đối tượng đầu tiên để gọi thông qua giao diện con trỏ chỉ tới các đối tượng thứ hai, sau đó một lỗi đã xảy ra, bởi vì các Thứ hai đối tượng không có nghĩa là để được gọi là trực tiếp từ thứ hai căn hộ. Nếu các đối tượng đầu tiên đang nắm giữ một con trỏ đến một proxy để các Thứ hai đối tượng thay vì một con trỏ trực tiếp, điều này sẽ gây ra một khác nhau lỗi. Hệ thống proxy cũng là đối tượng COM có liên quan đến một trong những và chỉ có một căn hộ. Họ theo dõi của căn hộ của họ để tránh circularities nhất định. Vì vậy một đối tượng gọi ra trên một proxy liên kết với một căn hộ khác nhau hơn so với các chủ đề mà trên đó các đối tượng đang chạy sẽ nhận được RPC_E_WRONG_THREAD trở lại từ các proxy và các cuộc gọi sẽ thất bại.

Luồng khả năng tương tác mô hình giữa khách hàng và các đối tượng trong quá trình

Tất cả các kết hợp của các mô hình luồng khả năng tương tác được phép giữakhách hàng và các đối tượng trong quá trình.

COM cho phép tất cả các khách hàng mẫu STA để inter-operate với luồng đơncác đối tượng trong proc bằng cách tạo và truy cập vào đối tượng trong các khách hàng của chínhSTA và marshaling nó cho khách hàng STA được gọi là CoCreateInstance [ví dụ].

Nếu một MTA trong một khách hàng tạo ra một mô hình STA trong proc máy chủ, COM quay lên một"chủ" STA trong các khách hàng. Máy chủ này STA tạo ra các đối tượng và cácgiao diện con trỏ marshaled quay lại MTA. Tương tự như vậy, khi một STAtạo ra một máy chủ trong proc MTA, COM quay lên một máy chủ lưu trữ MTA trong đó đối tượngđược tạo ra và marshaled quay lại STA. khả năng tương tác giữa cácmô hình luồng đơn và MTA mô hình được xử lý tương tự như vậy bởi vì cácmô hình luồng duy nhất là chỉ là một trường hợp thoái hóa của các mô hình STA.

Marshaling mã phải được cung cấp cho bất kỳ tuỳ chỉnh giao diện mà trong proc tỷmáy chủ thực hiện nếu nó muốn hỗ trợ khả năng tương tác đòi hỏi COMđể marshal giao diện giữa các khách hàng căn hộ. Xem các tài liệu tham khảophần dưới đây để biết thêm thông tin.

Mối quan hệ giữa các mô hình luồng và đối tượng lớp nhà máy quay trở lại

Một định nghĩa chính xác của máy chủ trong proc đang được "nạp vào" căn hộ làgiải thích trong hai bước sau đây:

  1. Nếu tệp DLL có chứa lớp máy chủ trong proc đã không trước đây được nạp (được ánh xạ vào trong không gian địa chỉ quá trình) bởi các hoạt động hệ thống nạp, thao tác được thực hiện, và COM lấy được địa chỉ chức năng DLLGetClassObject xuất khẩu bởi DLL. Nếu tệp DLL có trước đây đã được nạp bởi một chủ đề liên kết với bất kỳ căn hộ cao cấp, điều này giai đoạn được bỏ qua.
  2. COM sử dụng thread (hoặc, trong trường hợp của MTA, một trong các chủ đề) liên kết với căn hộ "nạp" để gọi DllGetClassObject chức năng xuất khẩu của DLL yêu cầu CLSID giai cấp cần thiết. Đối tượng nhà máy quay trở lại sau đó được sử dụng để tạo ra trường hợp của các đối tượng lớp.

    Bước thứ hai (gọi DllGetClassObject bởi COM) xảy ra mỗi và mỗi khi một khách hàng gọi CoGetClassObject/CoCreateIntance [ví dụ], thậm chí từ trong cùng một căn hộ. Nói cách khác, DllGetClassObject có thể gọi là nhiều lần bởi một thread gắn liền với cùng một căn hộ chung cư; tất cả phụ thuộc vào bao nhiêu khách hàng trong căn hộ đó đang cố gắng để có được quyền truy cập đối tượng nhà máy sản xuất lớp cho lớp đó.
Tác giả của lớp hiện thực, và cuối cùng, tác giả của DLLgói một tập cho các lớp học đã hoàn toàn tự do để quyết định những gìnhà máy đối tượng để trở về để đáp ứng với các chức năng DllGetClassObjectcuộc gọi. Tác giả của các gói DLL có nói cuối cùng bởi vì mã"đằng sau" mục nhập DLL toàn DllGetClassObject() duy nhất điểm là những gì đãđầu tiên và cuối cùng có khả năng quyền quyết định những việc cần làm. Bakhả năng tiêu biểu là:

  1. DllGetClassObject trả về một đối tượng duy nhất lớp nhà máy trên mỗi điện thoại chủ đề (có nghĩa là một trong những đối tượng lớp nhà máy trên mỗi STA và có khả năng các nhà nhiều lớp máy trong MTA).
  2. DllGetClassObject luôn luôn trả về đối tượng lớp nhà máy tương tự, bất kể về nhận dạng của sợi chỉ gọi điện thoại hoặc các loại của căn hộ có liên kết với thread gọi điện thoại.
  3. DllGetClassObject trả về một đối tượng duy nhất lớp nhà máy trên mỗi điện thoại căn hộ (một cho mỗi căn hộ ở cả STA và MTA).
Có những khả năng khác cho mối quan hệ giữa các cuộc gọi đếnDllGetClassObject và đối tượng lớp nhà máy thực sự trở lại (ví dụ như mộtmới đối tượng lớp nhà máy trên mỗi cuộc gọi đến DllGetClassObject) nhưng họ không làm như thếhiện nay xuất hiện để đặc biệt hữu ích.

Bản tóm tắt của khách hàng và đối tượng luồng các mô hình cho các máy chủ trong Proc

Bảng sau đây tóm tắt sự tương tác giữa khác nhauluồng mô hình khi kêu gọi một sợi khách hàng đầu tiên các CoGetClassObject mộtlớp học được thực hiện như một máy chủ trong proc.

Các loại khách hàng/chủ đề:

  • khách hàng đang chạy trong một chủ đề liên quan đến STA "chính" (đầu tiên Thread để gọi CoInitialize hoặc CoInitializeEx với COINIT_APARTMENTTHREADED cờ)-gọi này STA0 (cũng được gọi là đĩa đơn - luồng mô hình).
  • khách hàng đang chạy trong một chủ đề liên quan đến trong bất kỳ cuộc gọi STA [ASCII 150] khác STA này *.
  • khách hàng đang chạy trong một chủ đề liên quan đến trong MTA.
Các loại DLL máy chủ:

  • Hệ phục vụ đã không có phím ThreadingModel--gọi đây là "Không."
  • Máy chủ được đánh dấu "Căn hộ" - gọi này "Apt."
  • Máy chủ được đánh dấu "Tự do."
  • Máy chủ được đánh dấu "Cả hai."
Khi đọc bảng dưới đây, hãy ghi nhớ định nghĩa được thực hiện trên của"nạp" trình phục vụ vào một căn hộ.
Client     Server     Result------     ------     -----------------------------------------STA0       None       Direct access; server loaded into STA0STA*       None       Proxy access; server loaded into                      STA0.MTA        None       Proxy access; server loaded into STA0; STA0 created                      automatically by COM if necessary;STA0       Apt        Direct access; server loaded into STA0STA*       Apt        Direct access; server loaded into STA*MTA        Apt        Proxy access; server loaded into anSTA created automatically by COM.STA0       Free       Proxy access; server is loaded into MTAMTA created automatically by COM if necessary.STA*       Free       Same as STA0->FreeMTA        Free       Direct accessSTA0       Both       Direct access; server loaded into STA0STA*       Both       Direct access; server loaded into STA*MTA        Both       Direct access; server loaded into the MTA				
THAM KHẢO
SDK tài liệu trên CoRegisterMessageFilter() và IMessageFiltergiao diện.

Để biết thêm chi tiết, xin vui lòng xem các bài viết sau đây trong cácCơ sở kiến thức Microsoft:
136885 OLE đề phải gửi tin nhắn
137629 Trong proc đối tượng tùy chỉnh giao diện trong căn hộ mô hình ứng dụng khách

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 150777 - Xem lại Lần cuối: 08/18/2011 09:00:00 - Bản sửa đổi: 2.0

  • kbinfo kbmt KB150777 KbMtvi
Phản hồi