Interprocess sync practice

Now we are working on an addin project. It was just a simple thing. A new feature demand gave me the opportunity to get a bit of Interprocess code. Although coding is not complex, it does deepen the understanding of Interprocess sync. Note it down.

Requirement: This addin involves two applications. The original behavior is that every time I call another application (app2) from an app (app1) through addin to complete some work, I start a new process instance, the user complained that the startup speed was too slow and hoped to reuse the opened app2. However, before the work in app2 is completed (return to app1 button click), app1 must be in the freeze state.

Analysis and Implementation:

There are two key points:

1) How to reuse an opened app2. Solution: You already have the launchapp.exe program dedicated to this task.

2) how to lock app1. Solution: This uses the inter-process communication facility. In short, it is a class called Signal semaphore, including mutex, event, and critical section. They are actually some global data or access points that can be accessed across processes or threads. What I need to do is to create a cross-process signal object (such as event or mutex) in addin of app1 and keep it waiting; in app2, the cross-process signal object is used to send a signal to app1 to inform him of the completion of the work, so that app1 can resume work. After research, only manual reset event can be used, because only manual reset event can be set to be in the signal or not in the signal state. Practice: In addin of app1, createevent is initialized to the notsignal state, and then the addin enters the loop of waiting for the event to change to the signal State; in app2, openevent to get the event handle created in app1, and setevent to change the event to signal status. In this way, the waitforsingleobject in app1 can obtain the access permission of the event (the premise is that the event is in the signal state), so that it can continue to execute unlocked.

Summary:

1. Net remoting. Write down one point: when launcher connect to the remote object in app2, a new thread is actually added to the app2 process for execution. The problem I encountered was that when I tried to change the UI of app2 in that new thread, I threw an exception and told me: "another thread owns the object ". Another thread refers to the main thread. Therefore, the work done in that new thread is very limited. To do things such as opening documents and changing the UI, you need to use postmessage to ultimately do things in the main thread.

2. interprocess sync. Essentially, these so-called semaphore objects can be considered OS-level global variables, so they can be accessed by processes. Note: donet provides system. threading and the following classes, while native C ++ has a set of sync functions. This article compares various signal Methods: synchronization objects for interprocess synchronization and multi-threadiing. Based on my current understanding, other signal objects except manual reset event are in the signal state by default, therefore, any thread or process listening to it can obtain its right to use (once it is idle), applicable to situations where there is no requirement on the execution sequence of the thread or process; while manual reset event, it can be out of the non-signal state, which can be used to precisely control the execution sequence of threads or processes in a certain period of time. For example, the problem I encountered has such a requirement.