There seems to be some confusion whether VFP mtdlls are indeed multi-threaded. My contention is that they certainly are. The argument seems to be that if they are not "Free-threaded" like .NET applications can be, then they are only simulating being multi-threaded. This is kind of a .NET biased way of thinking about things, IMHO. VFP mtdlls are "apartment threaded" and only 1 thread can be in any single apartment at any time(hence the term STA). However, for each thread, there is an apartment. Therefore, there can be multiple threads running at any time(and multiple apartments). I believe this is the definition of multi-threading. If it were not multi-threading, there would be some sort of blocking going on in the first thread, which is not the case. Free threading, as is found in .NET and C++, is undoubtedly more efficient, but to claim it is the only true form of multi-threading is ridiculous. The difference between Apartment and Free-threading is that,in the Free-threading model, more than one thread can be active in an apartment. VB6 uses apartment multi-threading also, BTW.
Here is some background and information for VFP mtdlls multi-threading in various environments:
http://www.calvinhsia.com/papers/AdvancedVFPServers.mht (VFP multi-threaded from C++, IIS, Java)
http://www.techvanguards.com/com/concepts/multithreading.asp (Good explanation of STA)
http://www.west-wind.com/presentations/aspobjects/ASPObjects.htm (Understanding ASP/COM scalability)
Another big plus for vfp mtdlls is that the VFP runtime is loaded only once and shared by the multiple vfp threads.
Here's some things from Understanding and Using COM Threading Models
- An apartment is not a thread. The one-to-one relationship between threads and single-threaded apartments may lead you to believe that the two terms are interchangeable—they are not.
- A single-threaded apartment is associated with the thread that created it, and only that specific thread may execute calls on objects within the apartment. By contrast, a multi-threaded apartment is not associated with any particular thread. It may be called concurrently by any number of threads and objects within it and should subsequently protect their member data.
- Although multi-threaded apartments, sometimes called free-threaded apartments, are a much simpler model, they are more difficult to develop for because the developer must implement the thread synchronization for the objects, a decidedly nontrivial task.
VFP COM DLLs are definitely not free-threaded.
- A process has one single-threaded apartment (STA) for each thread that called CoInitialize. Each of these apartments, in turn, may have zero or more COM objects associated with them. As the name implies, however, only one specific thread (the thread that created the apartment by calling CoInitialize) may directly access the objects within the apartment. Once associated with an apartment, a thread cannot be associated with another apartment or change the concurrency model of its apartment.
To create an STA, a thread simply calls CoInitialize or CoInitializeEx(NULL, COINIT_APARTMENTTHREADED), thereby associating the calling thread with the apartment until it calls CoUninitialize. Successive calls to either of these functions by the same thread do not create additional apartments or enable you to change the concurrency model of the apartment.
- To avoid this sluggishness, be sure to specify the STA registry value ThreadingModel=Apartment. This states that a component's global data and DLL entry points are thread-safe which, in turn, allows multiple instances of this component to be created in any number of STAs.
Furthermore, when discussing Multi-threaded apartments, the article also states, In-process components written for MTA use the ThreadingModel registry value (ThreadingModel = Free) to indicate to clients that they should be created in the MTA.
Look at the type library information from a VFP MTDLL and you'll see ThreadingModel=Apartment.
VFP COM DLLs are NOT multi-threaded, but rather single-threaded apartment model.
I don't think you stated anything different than I did, yet you jumped to your conclusion in your statement that:"VFP COM DLLs are NOT multi-threaded". Everything you quoted said that VFP mtdll are not "free-threaded". You're obviously getting multi-threading confused with free-threading...
There's no confusing between MT and FT. My point is...and one you agreed with...is that VFP MTDLLs are STA. Note, by definition, this is single threaded. See Processes, Threads, and Apartments (emphasis my own)
There are two types of apartments: single-threaded apartments, and multithreaded apartments.
Single-threaded apartments consist of exactly one thread, so all COM objects that live in a single-threaded apartment can receive method calls only from the one thread that belongs to that apartment. All method calls to a COM object in a single-threaded apartment are synchronized with the windows message queue for the single-threaded apartment's thread. A process with a single thread of execution is simply a special case of this model.
Multithreaded apartments consist of one or more threads, so all COM objects that live in an multithreaded apartment can receive method calls directly from any of the threads that belong to the multithreaded apartment. Threads in a multithreaded apartment use a model called free-threading. Calls to COM objects in a multithreaded apartment are synchronized by the objects themselves.
STA does NOT mean single-threaded. Why are you jumping to this conclusion? STA means "single-threaded apartment". In a vfp mtdll, there are many threads and many apartments(yes, one thread to one apartment, but, so what - there's no blocking of other threads at the same time) all working simultaneously, thus multi-threaded. Your argument seems to be that there is only 1 apartment at any single time which is not true...
That is not my argument at all. It's back to semantics. You can have more than one apartment running at a time, each with one thread. But that in no way means multi-threaded. It means multiple apartments. The semantics of this indicate that because multiple threads are running, it is multi-threaded. This is not the case. Let's look at an example. I'll let you provide the answers. For this discussion, let's use IIS as the host application. Session A instantiates the VFP MTDLL. As this is the first hit, it loads from disk. Now, while Session A is still using the DLL, Session B makes a call. Does Session B load a second copy of the DLL from disk or does it use the one already in memory?
I don't think it matters although I'd like to know exactly what it is loading (especially if it is really reloading the VFP runtime every time)But here's the best, most thorough link I've seen on the topic:
A key passage is
"Here's a few important characteristics of the STA:
There is 1 and only 1 thread in an STA. All objects that reside in the STA are serviced on this one thread.
A server can implement multithreading by creating multiple STAs. Since an STA contains 1 thread, multiple STAs result in multiple threads. Furthermore, each STA can "house" more than 1 object. This prevents the server from excessively creating a lot of STAs!"
(Also, weren't you the one that said this had nothing to do with semantics?)...
It turns out that vfp mtdlls share a single copy of the vfp runtime (vfp?t.dll). My guess is that the vfp mtdll application is also being shared from memory to all threads. Maybe someone can confirm this...
Although this is an old thread (last changed in 2006), the topic is still relevant, and there was no clear conclusion drawn.
It is apparent that semantics and definitions have caused some confusion, along with what VFP does, and what some developers want it to do.
1) Multi Threaded -- Multiple threads execute the same code from the same location in memory.
2) Single Threaded -- For each thread executing, there is a copy of code in memory being executed.
3) STA - SingleThreadedApartment - One block of code in memory can be associated with multiple apartments (containing data, I believe). Each Apartment gets exactly one thread that is allowed to access (run in) it. This means it IS Multi Threaded. However: No thread can touch the data in any other thread. The threads communication only via data on the disk or through Windows messages. This makes the multithreading useless from the programmer's perspective: It really does save memory, and it enables a server to host multiple threads without using a ton of memory. But the programmer doesn't have to know about it, and can't do anything special even if he/she does know about it.
4) MTA - MultiThreadedApartment - AKA "Free Threaded" -- One block of code in memory can be associated with multiple apartments (containing data, I believe). Each Apartment gets one or more threads that are allowed to access (run in) it. If one thread changes data in the apartment, all other threads in that apartment immediately see the new data: This can be a good thing or a bad thing, depending on how well the code is debugged.
I believe the above is a correct summary that highlights why a programmer would argue that VFP is not multithreaded.
Here is a tool that may enable VFP applications to achieve background processes without wasting memory: http://www.geocities.com/rremus/multithreaded_vfp.htm (I haven't tried it, just read about it. I think it might enable what is most longed for, without any of the "dangers" of true MTAs... ie. no race conditions, or other interacting between threads. ) - wgcs
Regarding STA, why do you say "This makes the multithreading useless" ? You really need to try some of this before you make those types of statements. Can you give an example where you want to "touch the data in the other thread"??
Probably the main reason we have multi-threading vfp dlls is for web programming and it does that extremely well (see activevfp or foxtrails).
Examples are the best proof for all of this and the more practical the better. How about running routines in the background for a desktop vfp app like printing reports or running calculations: try http://www.codeplex.com/mtmyvfp or http://www.portalfox.com/articulos/archivos/bozzo/Test_Threads.zip - both based on vfp mtdlls. Or my favorite, VFPWebcrawler which allows you to specify any # of threads to search the web in the background and update shared dbfs while keeping the desktop app totally responsive.
I'm afraid alot of what you said is adding to the noise about this subject in vfp..
See also Parallel Fox
Category Parallel Processing Category Needs Refactoring
( Topic last updated: 2015.07.15 05:19:28 AM )