同步运行.NET应用程序 [英] Syncronizing running .NET apps

查看:55
本文介绍了同步运行.NET应用程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

各位大家好!



我正在开发一个带有3D图形窗口的.NET应用程序,用于组装3D模型(我们称之为GAPP)。我还在开发一个CAM应用程序的.NET插件 - 我们称之为CAPP(第二个运行进程),它需要访问GAPP的应用程序对象,因为CAPP想要使用相同的3D GAPP的图形窗口,作为CAPP创建的模型的演示者。 GAPP必须独立于任何外部CAM插件,CAPP可以引用任何内容。



我正在寻找最好的架构来完成这项任务。



常见的场景是:

用户启动GAPP,使用它然后他决定使用CAPP加载项启动CAM sw。我不想重新启动GAPP或者有更多正在运行的GAPP。



但是我不知道这在.NET中是否可行。



在COM中,你有一个GetObject(name)方法,它返回一个正在运行的COM对象。



你有什么建议吗?对于我的问题?



谢谢!

Hello everybody!

I am developing a .NET application with 3D graphic window for assembling 3D models (lets call it "GAPP"). I am also developing a .NET addin to a CAM application - lets call it "CAPP" (a second running process), which will need to have access to "application object" of "GAPP", because CAPP wants to use the same 3D graphic window of "GAPP" as a presenter of models created by CAPP. The "GAPP" must be independent from any external "CAM addin", and the "CAPP" can reference anything.

I am searching for the best architecture to do this task.

the common scenario will be:
the user starts GAPP, work with it and then he decides to start the CAM sw with the CAPP add-in. I dont want to restart the GAPP or have more running GAPPs.

But I dont know if this is even possible in .NET.

In COM, you have a GetObject("name") method which returns you a running COM object.

Do you have any suggestions for my problem?

Thank you!

推荐答案

我会严肃质疑你的一般架构。在一个过程中运行它并不是更好吗?这样,你仍然可以执行应该在不同线程中并行执行的内容,并使用.NET线程同步原语同步它们。



首先,请注意它不会损害解决方案的模块性,甚至可以改进它们。相互引用并由相同进程加载的独立程序集比单独的进程生成更好的模块,这些进程是完全隔离的。至于单独进程的同步,如果您对这些进程进行编程以参与此类协作,则很有可能。这种方法有明显的缺点:

I would seriously question your general architecture. Isn''t it much better to run it all in one process? This way, you could still execute what should be executed in parallel in different thread and synchronize them using .NET thread synchronization primitives.

First of all, please note that it does not compromise modularity of the solutions or can even improve them. Separate assemblies referencing each other and loaded by the same process make better modules than separate processes, which are well isolated. As to the synchronization of separate processes, this is quite possible, if you program these processes to participate in such collaboration. This approach has apparent drawbacks though:


  1. 同步会增加系统内存使用和执行时间的开销。
  2. 同步对象在单独进程的地址空间中作为不同对象工作,因为这些地址空间是隔离的。要在不同进程中使用相同的同步对象,需要对它们进行命名。它需要创建系统唯一的名称( atoms )。这是一个单独的麻烦:你需要保证名称的唯一性,并且可能在唯一性失败时处理这些情况,因为由于某些巧合,一些其他不相关的过程已经创建了相同的原子。这样,组件共享某些共享程序集中定义的一些硬编码原子名称的明显简单方法可能会失败。
  3. 基于这种方法的解决方案的支持更加困难。
  4. 基于多个流程调试解决方案是非常困难的。比使用单进程多线程解决方案困难得多。

  1. Synchronization creates bigger overhead in system memory usage and execution time.
  2. Synchronization objects work as different object in address spaces of a separate processes, as those address spaces are isolated. To use of identical synchronization objects in different processes requires naming of them. And it requires creation system-unique names (atoms). This is a separate hassle: you will need to guarantee uniqueness of the names and probably handle the cases when uniqueness is failed, because, due to some coincidence, some other unrelated process already created the identical atom. This way, the apparently simple approach where the assembly share some hard-coded atom names defined in some shared assembly may fail. It''s pretty difficult to avoid such clashes with 100% guarantee.
  3. Support of the solutions based on such approach is more difficult.
  4. Debugging of the solution based on multiple processes is considerably more difficult than with a single-process multi-threaded solution.





不幸的是,我不熟悉您的架构和你的终极目标。所以,我无法建议最终解决方案。



因此,我仍然可以想象无论出于何种原因,都可能需要多工艺解决方案。您仍然可以在.NET项目中进行同步。例如,让我们考虑使用 mutex ,这是你在大多数典型案例中使用的东西。请参阅:

http://en.wikipedia.org/wiki/Mutex [< a href =http://en.wikipedia.org/wiki/Mutextarget =_ blanktitle =New Window> ^ ],

http://msdn.microsoft.com/en-us/library/system.threading.mutex.aspx [ ^ ] 。



轻量级的无名互斥锁不能在不同的进程中运行。 (回到线程:同步需要比互斥锁更简单,更健壮的设备:锁定语句, http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx [ ^ ]。)



您需要使用 Mutex 带有用于传递名称的字符串参数的构造函数。您尝试按名称创建新的或已存在的 Mutex 实例。如果某个其他进程在同一名称下创建了一个实例,则该实例已经存在。在创建和实例之后,您可以从out参数中了解它是否是新的(请参阅下面对构造函数帮助页面的最后两个引用)。因此,您需要使用以下一个或多个构造函数:

http ://msdn.microsoft.com/en-us/library/f55ddskf.aspx [ ^ ],

http://msdn.microsoft.com/en-us/library/bwe34f1k.aspx [ ^ ],

http://msdn.microsoft.com/en-us/library/9zf2f5bz.aspx [ ^ ]。



-SA



Unfortunately, I am not familiar with detail of your architecture and your ultimate goals. So, I cannot advise a final solution.

Therefore, I still can imagine that the multi-process solution may be required by whatever reasons. You still can do synchronization in .NET projects. For example, let''s consider the use of mutex, something which you would use in most typical cases. Please see:
http://en.wikipedia.org/wiki/Mutex[^],
http://msdn.microsoft.com/en-us/library/system.threading.mutex.aspx[^].

A light-weight unnamed mutex will not work across different process. (Going back to threads: the synchronization would require even more simple and robust device than a mutex: a lock statement, http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx[^].)

You will need to use Mutex constructors with a string parameter used to pass name. You try to create new or already existing instance of Mutex by name. An instance can already exist if some other process created one under the same name. After creation and instance, you can learn if it is new or not, from out parameter (please see two last references to the constructor help pages below). So, you will need to use on or more of the following constructors:
http://msdn.microsoft.com/en-us/library/f55ddskf.aspx[^],
http://msdn.microsoft.com/en-us/library/bwe34f1k.aspx[^],
http://msdn.microsoft.com/en-us/library/9zf2f5bz.aspx[^].

—SA


这篇关于同步运行.NET应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆