Can any body tell me what is the difference between loading dynamic library (which is internally calling COM dll) in main thread and worker thread.
Thanks in advance
Mostly, due to the support of the application development language, there is little need for special on the main thread to use COM.
For example, check the OLE/COM option with the project creation wizard.
However, when using multiple worker threads and using COM in the worker thread, the following actions are necessary.
Worker threads using COM must initialize OLE at the beginning of the thread (before creating/using COM objects).
For Win32 API, it is CoInitialize()/CoInitializeEx(). Alternatively, depending on the application development language, there will be equivalent functions and libraries, so please call it.
Worker threads that use COM must perform their own message processing loop independently of Windows message processing loop performed by the main thread responsible for UI.
Please pay attention to the COM component being used.
If the value of ThreadingModel in the registry in which the COM component is registered is an empty string (nothing is set), an event may not be notified to the work thread and an exception may be raised.
If there is no value in this registry please write "Apartment".
Please use COM object basically only from the created thread.
If a COM object is called from another thread that is not the thread that created the COM object, an error may occur or normal operation may not be performed.
Additional notes:
In order to terminate the worker thread, it is necessary to perform the above cleaning up.
Terminate and release COM object, stop message processing loop, call CoUnintialize(), and so on.
Resources created/allocated within the worker thread must be terminated/released.
Related
I have two processes: a Client and a Server. Client makes a call that the Server starts processing, but the Server can start shutting down before the call is finished. This can cause objects required by the call to suddenly become destroyed, leading to a crash.
The Client and Server communicate through COM. Something that tells the amount of currently active RPCs from and to a given Server process would be extremely helpful in this case.
Does COM, as the layer of communication between these two processes, provide any aid in delaying shutdown when there is active interaction them?
I don't know which langage has been used to implement your COM client/server.
But as far as I understand, it looks like you are facing a COM multithreading issue. What is the threading model of your COM server? (I suppose it multithreaded)
If it's the case, you should synchronize your threads.
The over way would be to transform the threading model of your COM server into a single threaded model. In that case, server shutting down call will be executed after previous client call finishes.
I suspect you really want CoAddRefServerProcess inside your C++ object's constructor (and CoReleaseServerProcess in the destructor).
This will keep your server alive until the C++ objects go away.
However, this won't prevent the client from requesting new instances, so you may also want:
CoRevokeClassObject to prevent new instances of the client from obtaining proxies.
If you're feeling really nasty, CoDisconnectObject will forcibly disconnect the proxy from the server.
*
The GUI of my program freezes while the program is doing its work. I created a mass import which can send X-thousand datarows via a called webservice into a database. The code is already very big and I cannot rewrite it for multithreading purpose.
I don't know how to do it. Any suggestions? If needed I will show some code, but at the moment I don't know what to show.
Firstly, you should rewrite it to use avoid synchronously doing this on the UI thread. If you do a lot of work on the UI thread, it simply will freeze the UI thread. There are a few options here:
If your web service proxy supports asynchronous calls, and if you're using VB 11, you can use Async / Await to call the web service asynchronously from the UI thread in an asynchronous method, and control will return back to the UI thread at the same point in the asynchronous method when the call has completed. It takes a little while to get your head round asynchrony, but this is probably the best option if it's possible.
You can use the Task Parallel Library to make calls on a different thread, but then you'll need to think carefully about how that thread is going to interact with your UI thread.
You can use BackgroundWorker to run some code on another thread, but report progress and completion back on the UI thread
You could potentially call Application.DoEvents between each web service call, to let the UI handle events. This is dangerous - it can lead to re-entrant code, so locks won't behave as you expect them to, and similar hard-to-diagnose errors. This should be your last option, if all else fails.
I am working on a bug that related to an unmanaged MTA COM object. The object has Lock and Unlock methods and uses a mutex that requires the same thread that called Lock to call Unlock.
The problem is that when Lock and Unlock are called from a managed STA thread (using COM interop), the calls come into the COM object on a RPC callback thread but the callback thread that is used is not always the same for both calls. When it is not the same, the Unlock call fails because it can't unlock the mutex.
In other words:
Managed STA thread 1 -> RPC callback (thread 11) -> Lock
Managed STA thread 1 -> RPC callback (thread 12) -> Unlock -> Error
I am trying to evaluate all possible solutions before making any decisions on a fix. As such, I am trying to find out:
1) Is there is a way to prevent a RPC callback thread from being used in the first place? In my testing, if I make the calls to the object from an unmanaged STA thread, the calls seem to come in on the calling thread itself. What is different when the call is coming from .Net that necessitates the use of an RPC callback thread? Is there any way to prevent RPC callbacks from being used? (except for using an MTA calling thread)
2) If not, is there a way to force a consistent RPC callback thread to be used from the same managed STA thread?
This is by design for a free-threaded server. COM takes your word for it and allows stubs to use arbitrary RPC threads. You cannot make any assumptions about the thread identity, the RPC thread is picked from a pool and is recycled. Unfortunately it often picks the same one when the calls are sequenced so it will look like it works fine at first. But trouble starts as soon as more than one concurrent server call is made. There is no option to make it selective, a free-threaded server promises to not care. Nor could that work well in practice, it would either scale horribly or induce deadlock.
You therefore cannot use a mutex to implement locking, it has thread affinity. A semaphore is a good choice.
I have an out of proc COM (ATL) Server that has been created as free threaded (CComMultiThreadModel)
I am slightly confused as to how that relates to the re-entrancy of calls into my object, for example I assumed that I would be allowed to call from multiple clients simultaneously and have those requests processed simultaneously however it seems (according to my logs) that each request is serialized.
What am I missing, does simply creating a class as MTA mean it truly is or is there something else I have to do. Note that I am referring here to multiple processes all making concurrent calls and not threads within a single process and thus COINIT_MULTITHREADED is not the problem.
This snippet from some MS documentation on MTA would seem everything should work out of the box:
Multiple clients can simultaneously call, from different threads, an object that supports free-threading. In free-threaded out-of-process servers, COM, through the RPC subsystem, creates a pool of threads in the server process and a client call (or multiple client calls) can be delivered by any of these threads at any time
No sooner than I asked it I found the answer, you need to specify #define _ATL_FREE_THREADED in stdafx.h
I have a WCF service method that I want to perform some action asynchronously (so that there's little extra delay in returning to the caller). Is it safe to spawn a System.ComponentModel.BackgroundWorker within the method? I'd actually be using it to call one of the other service methods, so if there were a way to call one of them asynchronously, that would work to.
Is a BackgroundWorker the way to go, or is there a better way or a problem with doing that in a WCF service?
BackgroundWorker is really more for use within a UI. On the server you should look into using a ThreadPool instead.
when-to-use-thread-pool-in-c has a good write-up on when to use thread pools. Essentially, when handling requests on a server it is generally better to use a thread pool for many reasons. For example, over time you will not incur the extra overhead of creating new threads, and the pool places a limit on the total number of active threads at any given time, which helps conserve system resources while under load.
Generally BackgroundWorker is discussed when a background task needs to be performed by a GUI application. For example, the MSDN page for System.ComponentModel.BackgroundWorker specifically refers to a UI use case:
The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.
That is not to say that it could not be used server-side, but the intent of the class is for use within a UI.