In my understanding, SYS(2336) is really only relevant for cross-thread synchronization. It's like a mutex that only lives within the space of a single process. So you can use it to keep a thread's execution in one apartment from munging up something that a thread in another apartment is doing.

Assume two objects live in the same apartment. In terms of access to the thread within that apartment, COM's built-in serialization of calls on the same thread prevents the execution of one object's code from being interrupted by another object living in that same apartment. So within the same apartment, when any object's method is invoked through the COM interface, COM itself is effectively imposing a critical section for that object's code (with respect ONLY to other objects on that thread) by serializing access to the thread. Only when the object's code returns to the client via the COM interface, as I understand things, can another object living in that apartment get a ride on the same thread.

The reason why all of this is so interesting to me is that, despite all the warnings, I think I've found some reliable and useful ways to use public memory variables and other static thread-local storage within an MTDLL to substantially increase the efficiency of the MTDLL. So far, so good. And I've been doing quite a bit of experimenting.


>I don't understand the rule regarding how many concurrently existing objects can be created on the same thread. I do understand that once a COM object is created on a thread in the STA model, it lives its entire lifetime on that thread.
>
>To keep the "ducks" in a row, there is: SYS(2336,1)/SYS(2336,2). A Calvin Hsia paper (Session: DNA08 - "Advanced Visual FoxPro Servers") offers a great description of VFP MTDLL. I'll look for a clean link - the one I just saw had formatting characters in the body.
>
>The SYS(2336) functions control the flow. I am new to VFP MTDLL - but I use it. My understanding is that it is not a true MTDLL (like ISAPI) that can be queried regarding the status or nature of other active threads (sessions). The advantage of VFP MTDLL, i think, is that instanciation does not replicate copies of it in memeory. I just use it as a single threader. Your client will only be aware if it's thread.
>
>I am waiting for for a VFP MTDLL service where one clients thread can "ask" the nature of another ("clients") thread.
>
>Once SYS(2336) "queues" a thread in, the thread can intanciate other objects. My simple stuff uses (newobject) a "session" class inside a SYS(2336) "thread" for a structure - and then throws them away (ISAPI).
>
>I don't typically use a COM as a "store". But, as long as the COM is connected, "your" client can reference "it's" properties. In true multi threading I think it is possible to refer to the status of other threads (sessionid).
>
>>
>>So in the STA model used by VFP MTDLLs, when an object is created on a thread, can another object of the same olepublic class be created on that same thread before the first object is destroyed? I mean, is this even possible? If it is possible, then there's a local storage issue that I don't understand. Or, is this a situation where the dispatcher decides "Thread A is still busy, so I need to create the next instance of the same object on Thread B (and in the process,maybe even create thread B)."
>>
>>Thanks very much.