C / C++ / MFC

4-Apr-08 0:31

Hello everyone,

In the book ATL Internals, here is the description for CComVariant. My questions,

--------------------
COM permits an object to hand out different binary values each time a client queries it for a specific interface pointer (with the exception of a query for the IUnknown interface). Therefore, two VARIANTs containing IDispatch pointers referencing the same object might not compare for equality.
--------------------

1.

I think it means even if the pointer binary values are different, they may still be pointed to the same object? Right?

I think it happens only in the situation of multiple inheritance, and in single inheritance, there is no such issue. Right?

2.

I think the above statement describes the following scenario, in multiple inheritance, suppose we have interface A inherits from IDispose, and interface B inherits from IDispose, and have inteface C inherits from both A and B.

The queryInterface for A and B from interface C will return different result.

thanks in advance,
George

Matthew Faithfull4-Apr-08 1:56

4-Apr-08 1:56

Nope, it has nothing to do with multiple inheritance, just the rules of COM that allow for transparent proxies and aggregation and all sorts of complex stuff. Each reference to an interface that a COM object hands out can be different because it might actually be refering to a different server side proxy. This doesn't really have much to do with VARIANTS and I don't think you need to worry about it. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 2:17

4-Apr-08 2:17

Thanks Matthew,

Two more comments,

1.

Matthew Faithfull wrote:
transparent proxies

I do not understand what do you mean? Do you mean retrieve the object instance directly compared retrieving the object instance by proxy?

2.

Matthew Faithfull wrote:
aggregation

If an object instance is aggregated, it should only be queried from outer interface. I do not think for the same object instance, you can get two different interface pointer address? Any more description please?

regards,
George

Matthew Faithfull4-Apr-08 2:32

4-Apr-08 2:32

George_George wrote:
Do you mean retrieve the object instance directly compared retrieving the object instance by proxy?

No I mean retrive the object instance directly compared to recieving a proxy for the object generated especially for you. ( This often happens with connection points )

George_George wrote:
Any more description please?

There are endless permutations and complication within COM and many of the rules can be 'bent' to meet extremely strange configurations at the server end. Part of the point of COM is that you don't have to know or care, play it by the book from your end and the rest will either work or it won't. The reality can sometimes be more complex but usually only because somebody somewhere broke the rules. Smile | :)

I once retrofitted a large MFC/MDI multithreaded desktop application so that it could also be launched remotely as a DCOM server with no visble UI but fully functional. Had to rework virtually the entire MFC Doc/View startup process to make it work under both conditions but COM wise it was all within the rules and the middleware using it as a backend was none the wiser. So cool when it worked. Big Grin | :-D

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 2:54

4-Apr-08 2:54

Cool, Matthew!

Why aggregation is used, for the same COM object, different interface pointer binary values could be retrieved? Any more description please?

regards,
George

Matthew Faithfull4-Apr-08 3:09

4-Apr-08 3:09

Again it's nothing specific to aggregration but an aggregate outside might choose to hand out a pointer to a different inside instance. One case where this might happen is where an aggregate is used to disguise a single threaded object as apartment threaded by creating multiple instances, once for each thread that enters the appartment. As I said almost anything is possible with enough ingenuity.

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 3:16

4-Apr-08 3:16

Thanks Matthew,

Matthew Faithfull wrote:
One case where this might happen is where an aggregate is used to disguise a single threaded object as apartment threaded by creating multiple instances, once for each thread that enters the appartment.

Looks cool. Your experience is so rich, I have never written code like that before. All the aggregation code I wrote before is about returning the pointer for the outer object when client requests for the inner object interface pointer through outer object's QueryInterface.

Now I understand the implementation is very flexible, and I should not stick to one fixed form. Smile | :)

regards,
George

Matthew Faithfull4-Apr-08 3:23

4-Apr-08 3:23

As the saying goes 'experience may vary', just because I got away with something once using an old version of ATL on VC6 doesn't mean it was ever a good idea or that you should be using it as a design guide. Coming up with ways to meet the spec, usually on the cheap and often wihtout a spec in the first place, that's what commercial software dev has always been about Laugh | :laugh:

On the other hand if you're just experimenting for fun then I'd say go for it, try anything once, even if it doesn't work at all you'll learn something new. Good luck.

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 3:37

4-Apr-08 3:37

Thanks Matthew,

Just want to make a final confirmation that, COM does not require query for interface for the same COM object returning for the same binary value, so even if we implement the way as you mentioned in the cool sample for thread-per-object-instance, the implementation does not violates the COM standard?

regards,
George

Matthew Faithfull4-Apr-08 3:55

4-Apr-08 3:55

If I remember my COM lore rightly then that is the case, it only requires that if you do return the same value it represents the same object but the only time it would be useful is if you're aggregating an existing object which is single threaded and you can't change it. Performance is likely to be mediocre at best with all the calls going from the MTA into separate STAs.
On the other hand a single front object for multiple internal objects, all of which can live in the MTA is a very reasonable and potentially useful design. The single coolest component I've ever designed was a little piece of middleware, an ATL Singleton which operated an internal thread pool for handling requests from multiple ASP Web Servers, each request was simply forwarded to the correct back end application instance according to the session ID of the Web user. This solved the persistent user state issue that prevented IIS being properly scalable for years. All old hat these days of course. Smile | :)

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 4:12

4-Apr-08 4:12

Cool, Matthew!

1.

Matthew Faithfull wrote:
On the other hand a single front object for multiple internal objects, all of which can live in the MTA is a very reasonable and potentially useful design.

I think you mean making an MTA thread/component as front end and STA as inner component, and communication between MTA and STA through marshalling, right?

2.

For the performance design you mentioned above, if you say performence improved or superior, it must have some parties to compare to. What is the inferior design you compared to?

3.

"mediocre" you mean good or not good? Sorry for my limited English skill. Smile | :)

regards,
George

Matthew Faithfull4-Apr-08 4:28

4-Apr-08 4:28

George_George wrote:
an MTA thread/component as front end and STA as inner component

No that is the slower design because of all the interappartment calls.

George_George wrote:
"mediocre"

means not very good.

If the inner components are free threaded but only ever called on the thread where they were created, by the outer component, then they all live in the MTA but don't have to worry about locking/synchronisation, you only have to do that in one place, in the outer component, plenty of speed and no deadlocks Big Grin | :-D

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George4-Apr-08 4:39

4-Apr-08 4:39

Thanks Matthew,

1.

"interappartment calls." you mean marshalling expenses? And message queue expenses for STA?

2.

Let me repeat your great idea to confirm I understand. Smile | :)

You mean using MTA at front end, and using free threaded inner component for worker thread in MTA, right? Since in your design, each component is only touched by one thread, no synchronization and lock issues are needed to be considered and coded, so performance is improved, right?

3.

I am hard to believe such a system with separated components which do not need to share data has any values. In your designed system, the inner components do not need to communicate with each other? At least I think they need to communicate with the single MTA front end component, which there is additional locks on the MTA front end, which degrades performance.

Any comments?

regards,
George

Matthew Faithfull4-Apr-08 4:53

4-Apr-08 4:53

George_George wrote:
1.

Yes.

George_George wrote:
2.

Yes.

George_George wrote:
3.

The system has value in limited situations such as if you're scaling a single user system up to a multi user system. If each inner component is tied to a one user and can work without much if any modification.
Yes you still need locks in the front end component as I said but only to protect the thread pool and this can usual be done with fairly efficient Critical Section locks. In the system I worked on the only 'communication' between the inner objects was that they shared a database. This was already protected for sharing anyway as it normally would be between multiple users.

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George6-Apr-08 15:50