Question about threading model options in VB 6.0
Hello,
I am programming a VB 6.0 application and I am trying to understand the threading options that are available.
Under the project properties I have a number of options:
(1) Apartment Threaded, (2) Single threaded,
There are also check boxes for
a) Unattended execution
b) Retained in Memory
c) Upgrade ActiveX controls
This is compiled as an ActiveX dll and I have chosen the "Apartment Threaded Option"
Does this mean that a separate instance of the ActiveX dll memory will be created for each thread that instantiates the object via a "CreateObject" call? The .dll will be running on one or more multithreaded processes, and each process thread may instantiate one or more of the objects.
Questions
Q1) AM I at risk for a collision and threads walking on each other on the Class Module, or am I protected by the apartment threading properties of having separate data for each thread.
Q2) Am I protected in the module sections of the .dll? The reason I ask this, is that the public variables in the module section appear to be persistent between threads. Is there anything like an "EnterCriticalSection" (similar to C++) to protect against reentrancy in the module if this is critical?
Q3) Let's say this COM .dll is created by 4 threads in one process and 3 in another: Do I then have 7 separate instantiations of this object?
q4) Are the module public sections across processes at risk of colliding?
I know this is a complex question, so I am offering 500 points to start. For a great answer, I'll give more!
CSchene
I am programming a VB 6.0 application and I am trying to understand the threading options that are available.
Under the project properties I have a number of options:
(1) Apartment Threaded, (2) Single threaded,
There are also check boxes for
a) Unattended execution
b) Retained in Memory
c) Upgrade ActiveX controls
This is compiled as an ActiveX dll and I have chosen the "Apartment Threaded Option"
Does this mean that a separate instance of the ActiveX dll memory will be created for each thread that instantiates the object via a "CreateObject" call? The .dll will be running on one or more multithreaded processes, and each process thread may instantiate one or more of the objects.
Questions
Q1) AM I at risk for a collision and threads walking on each other on the Class Module, or am I protected by the apartment threading properties of having separate data for each thread.
Q2) Am I protected in the module sections of the .dll? The reason I ask this, is that the public variables in the module section appear to be persistent between threads. Is there anything like an "EnterCriticalSection" (similar to C++) to protect against reentrancy in the module if this is critical?
Q3) Let's say this COM .dll is created by 4 threads in one process and 3 in another: Do I then have 7 separate instantiations of this object?
q4) Are the module public sections across processes at risk of colliding?
I know this is a complex question, so I am offering 500 points to start. For a great answer, I'll give more!
CSchene
ASKER
Hi,
Thanks for the reply...I need to read the reerences. I'll probably have more questions.
Cschene
Thanks for the reply...I need to read the reerences. I'll probably have more questions.
Cschene
ASKER
>You must turn on the Unattended Execution option and the Retained In Memory option before compilation to host a >Microsoft Visual Basic Enterprise Edition for Windows 6.0 component (Microsoft ActiveX DLL) in a multi-threaded environ
==========================
Ok, Are you saying that if I do not check those two boxes that even though I have specified "Aprtment threading" I am still, in effect, single threaded? The program that is invoking my dll IS multithreaded.
>= In conclusion, you have to check these check-boxes only if you plan to use Microsoft Transaction Server (MTS) or COM + >in order to create an enterprise level application. =
==========================
I am not using those applications, but I am runing in a process control enviroment where I must process parallel transactions through one or more servers. In particular I have a historian server (low priority but lots of data), and hi priority real time process servers...so I think the same principle applies.
++++++++++++++++++++++++++
Q2) Modules are available (and has visibility) to the whole application. So, you cannot protect them. Try to use classes and define the variables as members.
==========================
Are modules the same within a given process? I believe I can protect them, if need be, using a semaphore to prevent re-entracy. I believe I could even call a C/C++ .dll from VB if some feature to accomplish the "re-entracy blocking" were not available in VB. I'd rather not, but this application is extremely critical (runs oil refineries and chemical plants)
==========================
Ok, Are you saying that if I do not check those two boxes that even though I have specified "Aprtment threading" I am still, in effect, single threaded? The program that is invoking my dll IS multithreaded.
>= In conclusion, you have to check these check-boxes only if you plan to use Microsoft Transaction Server (MTS) or COM + >in order to create an enterprise level application. =
==========================
I am not using those applications, but I am runing in a process control enviroment where I must process parallel transactions through one or more servers. In particular I have a historian server (low priority but lots of data), and hi priority real time process servers...so I think the same principle applies.
++++++++++++++++++++++++++
Q2) Modules are available (and has visibility) to the whole application. So, you cannot protect them. Try to use classes and define the variables as members.
==========================
Are modules the same within a given process? I believe I can protect them, if need be, using a semaphore to prevent re-entracy. I believe I could even call a C/C++ .dll from VB if some feature to accomplish the "re-entracy blocking" were not available in VB. I'd rather not, but this application is extremely critical (runs oil refineries and chemical plants)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
"What kind of transactions do you have to process? "
I am processing alarming and process variable requests for a DCS (Distributed Control System) process control system. The DCS systems enable the operators to view and control the plant or process via graphical pictures that represent the plant. These displays are connected to what is, in essence, a real time data base that is typically distributed over as many as 100 or more computers. The displays show the information from this real time database and report system anomalies in the form of alarms.
These systems are usually highly redundant for the most dangerous processes and will often run for years without ever being shutdown. I have upgraded systems where a given node has been running for 3 years or more without ever being shutdown.
When software is upgraded, for example, one node in a redundant pair will be shutdown and reloaded but the process is still running on the alternate node while the new software is loaded. Once the new load is complete and the data bases synchronized, the other node in the pair is shutdown and reloaded. When this second node is shutdown, the process again fails over to the redundant partner so that the process control is never interrupted during the software upgrade.
A process variable would be something like temperature, pressure, flow rate, tank level, etc. The DCS systems have very stringent alarming and alarm reporting requirements and I am processing information that aggregates alarm and process information and very quickly points the operator/engineer to the source of a problem so they can correct it quickly.
For a large continuous process (oil refinery, chemical plants, etc) a problem that goes uncorrected for even a few minutes can result in a product, such as premium grade gas, being out of spec for hours or the entire day.
I am processing alarming and process variable requests for a DCS (Distributed Control System) process control system. The DCS systems enable the operators to view and control the plant or process via graphical pictures that represent the plant. These displays are connected to what is, in essence, a real time data base that is typically distributed over as many as 100 or more computers. The displays show the information from this real time database and report system anomalies in the form of alarms.
These systems are usually highly redundant for the most dangerous processes and will often run for years without ever being shutdown. I have upgraded systems where a given node has been running for 3 years or more without ever being shutdown.
When software is upgraded, for example, one node in a redundant pair will be shutdown and reloaded but the process is still running on the alternate node while the new software is loaded. Once the new load is complete and the data bases synchronized, the other node in the pair is shutdown and reloaded. When this second node is shutdown, the process again fails over to the redundant partner so that the process control is never interrupted during the software upgrade.
A process variable would be something like temperature, pressure, flow rate, tank level, etc. The DCS systems have very stringent alarming and alarm reporting requirements and I am processing information that aggregates alarm and process information and very quickly points the operator/engineer to the source of a problem so they can correct it quickly.
For a large continuous process (oil refinery, chemical plants, etc) a problem that goes uncorrected for even a few minutes can result in a product, such as premium grade gas, being out of spec for hours or the entire day.
Thank you for your answer. If you still have any questions, I'll be happy to help you. Thank you, also, for the expert points.
ASKER
You are welcome!
= In conclusion, you have to check these check-boxes only if you plan to use Microsoft Transaction Server (MTS) or COM + in order to create an enterprise level application. =
"When you start a new project the currently registered controls are the only ones available. If you start a VB5 project when the VB6 controls are registered, it will require the VB6 versions of the controls to run. The VB compiler allows you to set an existing project to not upgrade ActiveX controls. If you do not check this option, existing projects will be converted to use the VB6 controls. " : http://www.angelfire.com/biz/rhaminisys/vboledll.html
= In conclusion, you have to check this check-boxe only if you are using VB 5.0. =
"Single Threaded forces your ActiveX DLL to use a single thread for all its objects, even if the client is multithreaded. If you use Single Threaded on a Multithreaded client, the performance of your application will be degraded due to cross-thread marshaling, which is discussed later in this section. "
"Selecting Apartment Threaded will not guarantee that your ActiveX DLL will use multiple threads. If the client application is single-threaded, then all objects of the ActiveX DLL will be attached to a single thread. If the client application is multithreaded, objects of the ActiveX DLL will be distributed and attached to multiple threads accordingly. Reentrancy rules should be strictly adhered to using this threading model with an ActiveX DLL. "
http://www.geocities.com/SiliconValley/Bridge/2582/ClassF.htm
CreateObject call is used only for late-binding purposes. If you want performance, use "new" operator(ealy-binding).
Q1) What collisions are you affraid from? You wil won't get any collisions between threads when using Apartment model.
Q2) Modules are available (and has visibility) to the whole application. So, you cannot protect them. Try to use classes and define the variables as members.
Q3) Not necessarily. That will depend on COM runtime libraries.
Q4) Yes, if can override very easy a value of a variable declared in a module. (see Answer to Q2).
I hope that answer will help you. If you have more question, please ask.