0

My doubt is that, in STA whether calls to different methods in the same interface is queued? or calls to the same method in same interface is queued?

TuneFanta
  • 69
  • 1
  • 9
  • If you mean calls from another apartment, then yes - cross-apartment calls into STA are implemented as window messages, and are queued on the message queue. For details, see [INFO: Descriptions and Workings of OLE Threading Models](https://support.microsoft.com/en-us/help/150777/info-descriptions-and-workings-of-ole-threading-models) – Igor Tandetnik Jul 19 '18 at 16:29
  • calls are queued (using windows messages) only when there is the need to call methods from different apartments – Simon Mourier Jul 19 '18 at 16:29
  • No, the specific method does not matter, marshaling rules apply to all of them equally. How you obtained the interface pointer is what matters. – Hans Passant Jul 19 '18 at 16:30
  • Is synchronisation scope is method only or is it interface as a whole? – TuneFanta Jul 19 '18 at 16:37
  • I'm not sure what you mean by "synchronisation scope". Could you describe a specific scenario you are wondering about? – Igor Tandetnik Jul 19 '18 at 18:28

1 Answers1

2

First the oversimplification:

Single-Threaded Apartments (STA) are constructs used to synchronize COM objects, not methods. As long as everybody plays by the rules, you are guaranteed that the object can only be accessed by one client at a time, that is, only one method can be called at a time. No method in the same object (by which of course I mean 'same instance', not 'of the same class') will be called randomly by a different thread while you are in the middle of a different call.

If you need to provide more granular synchronization, for example, only one method body needs to be synchronized, then apartments are not the right mechanism for you. The most flexible approach is to make your object free-threaded and manually code your own synchronization where needed. It is more work of course.

Now, I need to be more precise because we're both just hand-waving a lot of very important details:

The real goal of Single-Threaded Apartments is to provide thread-affinity for the object. The COM object's code can only run in the thread that created the object, and nobody else. If a different thread needs to talk to your object, they have to wait until the thread that owns your object is available. The fact that in a lot of scenarios that means method calling is queued is a natural side-effect of that.

"A lot of scenarios?"

Yes. Because apartments don't prevent reentrancy. Your method A() can call another method B() on the same object. And B() can call A() back. Or A() can call object2->MethodX() which itself calls your own method D() while you're still in the middle of executing A(). Or A() can trigger an Event (see Connection Points) and the event handler can call a different method E() on your object. So, referring to COM apartments as a synchronization mechanism for objects is a bit of a simplification that can get you in trouble if you don't think about the details.

Of course, mutexes and other synchronization primitives are also thread-bound, so they have the same reentrancy caveats. But by using vague language it might make you think that apartments do something they don't. Thinking that in an STA object only one method can be active at a time is a dangerous mental model.

Thread-affinity was a key goal of Single Threaded Apartments because COM was designed to be the modern foundation for OLE (the thing where you can drag a range of cells of a spreadsheet into a Microsoft Word document), in a multithreaded world. OLE objects rely a great deal on graphical system resources to paint their images, and those resources are thread-affine.

Euro Micelli
  • 31,089
  • 7
  • 46
  • 66