下午好，
正如我之前在另一篇文章中所说，我必须计算地图上某些点之间的大约 8,000,000 个最短时间/路径距离，这些点的坐标是已知的。问题是，虽然直线距离计算起来很容易（而且很快），但有人告诉我，单线程应用程序在使用 MapPoint 计算这个距离数时可能会出现问题。问题是我对多线程一无所知...我目前正在 i7 - 720QM 环境中工作，所以我想使用所有 4 个核心来进行这些计算...有没有简单的方法可以做到这一点在 C# 或 C++ 中？
非常感谢。
Good afternoon,
As I said earlier in another post, I have to calculate some 8,000,000 shortest- time/path distances between some points in the map, the coordinates of which are know. The problem is that, while straight-line distances were easy (and quick) to calculate, someone told me that a single-threaded application can have problems calculating this number of distances using MapPoint. The question is that I know nothing about multi-threading... I am currently working on a i7 - 720QM environment, so I would like to use all the 4 cores to make these calculations... Is there any easy way of doing this in C# or C++?
Thank you very much.
发布评论
评论（2）
如果您对多线程完全陌生，我的建议是从 BackGroundWorker 组件开始，然后逐渐切换到更精细的线程概念。
如果您使用 ..net 4.0，任务并行库将为您提供简单的入门方法。
请参阅下面的链接
TPL
BackGroundWorker
If you are totally new to the Multithreading than my advice start with BackGroundWorker component as a starting point and gradually switch to more garnular threading concepts.
and if you are using ..net 4.0 than Task Parallel Library gives you easy way to start with.
See Links Below
TPL
BackGroundWorker
可能是我说这需要很长时间。 MapPoint 的 COM API 是单线程的。让它并行计算多个路线的方法是启动多个 MapPoint，每个 MapPoint 都有自己的线程。
因此，对于您的四核，您将启动 2-3 个线程。每个线程启动自己的MapPoint，然后使用它进行路由。每个核心不会有一个 MapPoint。除了操作系统开销和 I/O 开销之外，如果您观察单个 MapPoint 计算路线，您会发现更高版本部分是内部多线程的，并且可能需要大约 1.5 个内核（如果可用）。
还有很多需要注意的问题。 MapPoint 自己的垃圾收集并未针对批量路线计算进行优化。最简单的解决方法是定期重新启动每个 MapPoint 应用程序（至少每天一次，但可能更频繁）。
此外，某些操作（文件打开似乎是主要操作）无法同时由多个 MapPoint 调用。可能是因为他们试图打开同一个文件，但我没有进一步调查。您将需要实现自己的锁定机制来避免这种情况。
Saurabh 对 .NET 4 的建议听起来不错：我还没有愤怒地使用 .NET 4 的多线程 - 我的 MapPoint/.NET 线程体验是使用 .NET 2 的。
我不知道你的应用程序是什么，但你知道吗我销售的产品使用多处理器 MapPoint 进行批量路线距离/时间计算...:-)
That might have been me who said it would take a long time. MapPoint's COM API is single threaded. The way to get it to compute multiple routes in parallel is to start multiple MapPoint's, each on its own thread.
So for your quad core, you will start 2-3 threads. Each thread starts its own MapPoint, and then uses it for routing. You will NOT have one MapPoint per core. As well OS overhead and your I/O overhead, if you watch a single MapPoint compute a route, you will find that later versions are partially internally multi-threaded and can take about 1.5 cores if they are available.
There are also a lot of gotchas to watch out for. MapPoint's own garbage collection is not optimized for batch route calculation. The easiest workaround for this is to simply restart each MapPoint application at periodic intervals (at least once a day but probably more frequently).
Also, some operations (File Open seems to be the main one) cannot be called by multiple MapPoints at once. Probably because they are trying to open the same file, but I have not investigated further. You will need to implement your own locking mechanism to avoid this.
Saurabh's advice for .NET 4 sounds good: I have yet to use .NET 4's multi-threading in anger - my MapPoint/.NET threading experience is with .NET 2.
I don't know what your app is, but did you know that I sell a product that uses multi-processor MapPoint for batch route distance/time calculation... :-)