ActiveX EXE multi threading and global variables in modules

[axisdj]

Hello Group,

Over the last few years I have made an effort to fully understand how vb6 activeX exe achieve multi threading for vb6 apps.

My insight became a little more clear when I needed to move a http call to a thread this weekend. I discovered first hand that VB6 keeps two copies of the global variable ( to be thread safe I assume)

So to get my code working I had to sync the threaded class global with the main gui thread global variable ( via an event from class). It was really amazing to see that they were actually two separate address locations. The global was declared in a Module.

For the GURUS here please correct me if I am wrong, and maybe add more insight to this.

thank you!

[dilettante]

Maybe look at Thread Local Storage?

That's where the data in static modules is allocated.

[Elroy]

Hi Axisdj,

For me, you didn't give the full name of an ActiveX EXE. In its full glory, it should be called an out-of-process ActiveX EXE. And it's that out-of-process that's the key to what you're saying. In terms of Windows, it's an entirely separate process, with its own thread and its own memory address space. Therefore, of course any "global" variables are going to have different memory addresses. In fact, you can run these ActiveX EXEs on a server, so they might even be running on an entirely different CPU and using entirely different memory chips.

VB6 was just nice enough to provide us with some mechanisms for these separate processes to communicate with each other. And that's really the only difference between a VB6 program along with an ActiveX EXE, versus two entirely independent VB6 programs.

Good Luck,
Elroy

[dilettante]

Well since there isn't really such a thing as an "in-process EXE" it is redundant to specify "out of process."

I don't think he was talking about globals being shared between the client EXE and the server, but among the threads running in the server.

[DEXWERX]

Well you wouldn't want separate threads accessing the same memory location (your global) without synchronization.

I suggest sharing a global Object, so that the synchronization happens automatically through the interface marshalling.

edit: I see you've already done something similar, But I still suggest using a singleton Class shared/marshaled to all your threads with a property to access your "global". It's more straight forward than trying to sync separate globals, and it's guaranteed to be accessing the most up to date value. There would be more overhead, as each access would be marshaled. Something to consider before reworking your syncing.

[The trick]

Each thread in an ActiveX exe has its own global and static variables in TLS (if there are the multiple threads).
When you create an object in an ActiveX EXE it lives in the own process and all the objects of that EXE live in the this EXE. If you create the same object once again it'll live in the same process. The threading behavior depends on the threading model option in the Project properties dialog.
If you select the thread-per-object option each object'll live in the its own STA;
If you select the thread-pool option with single thread each object'll live in the single STA (main STA);
If you select the thread-pool option with the arbitrary number of the threads each object'll live in the thread from the thread pool. If you have reached the limit of the thread the new object'll share its global and static variables with the previous one in the same thread;
Also you can run an ActiveX Dll in a separate (surrogate) process. It's usually useful if you use a 32 bit VB6-ActiveX dll from an 64-bit process.