Проблема с потоками

Question

Имею следующую проблему...
Для работающей программы моделирования было решено использовать отдельный поток с помощью BackgroundWorker'а, чтобы пользователь мог запустив моделирование, продолжить работу с ArcMap'ом не ощущая "тормозов" и "подвисания".
Однако использовав BackgroundWorker я существенно потерял в скорости моделирования (вместо 7-10 мин оно занимает около 2 часов). Как мне кажется, проблема стоит в приоритете потоков в Windows. Итак, мой вопрос как правильно использовать BackgroundWorker и как регулировать приоритет потока?
Искренне надеюсь на помощь сведущих людей...

Answer 1

А мне например не понравился вызов LoadData из потока LoadDataAsync, и ещё у Вас не видно вот такой конструкции:

namespace ConsoleApplication1
{
  class Program
  {
    [STAThread]
    static void Main(string[] args)
    {
       // ...
    }
  }
}

Причём по теории СОМ, при использовании такой конструкции, не стоит инициализировать дополнительные STA, это всё равно не поможет...

Answer 2

и ещё у Вас не видно вот такой конструкции:

У меня? Вроде всё на месте.

-------------------------------
Немного модифицировал тест - стало интересно, как оно будет работать на моём двухъядернике.

Код перебирает все полигончики в слое (36 тысяч земельных участков в городе), вызывает ShapeCopy (чтобы чуть побольше поднагрузить COM) и считает общую площадь полученных полигонов.
Сначала запускаю этот код в основном потоке, затем в специально созданном фоновом потоке, затем запускаю код одновременно в основном и фоновом потоках.


1. Основной и фоновый - оба STA.



2. Основной - STAThread, фоновый - MTA.



3. Основной - MTAThread, фоновый - STA.



4. Основной и фоновый - MTA.


Видимо, параллелить смысл всё же есть. Понятное дело, не забывая указывать режим STA, а то будет только хуже.
Исходники прилагаются.


P.S. Файлы и картинки к посту прикреплять стандартными кнопками только одмины могут?

Answer 3

4 STA-потока на 2-ядернике:



Что и следовало ожидать. В общем, всё понятно.

Answer 4

Забыл сказать, это, конечно же, обычный C# Console Application.

вот в этом может быть и проблема
у меня-то не отдельное приложение, а расширение ArcMap

будет время, проверю загрузку на своих данных - отпишусь

PS во время работы по загрузке данных из отдельного потока в основном потоке я ничего не делаю

 

Answer 5

потестил с gdb, mdb и sde

в консольном приложении действительно все ок, особых тормозов нет
с отдельным потоком работает слегка медленнее - но это вполне ожидаемо

поэтому делаю вывод о том, что это очередная засада ArcMap'а

кстати, по ходу обнаружил еще такую вещь: код в том виде, как есть, отказался компиляться под VS2010 RC
под VS2008 собрался без проблем

разбираться, почему не работает под VS2010 - пока времени нет
да и нужды особой тоже - вот выйдет релиз, тогда и будем смотреть

Answer 6

Из ArcMap:

Исходник

------
Сейчас одна и та же задача выполняется независимо в наскольких потоках. Думаю, надо будет вечерком поделить задачу на несколько подзадач (по числу процессоров). Посмотреть, будет ли выигрыш с моим количеством объектов или накладные расходы всё сожрут.

Answer 7

1. мне неинтересна файловая база, у меня данные в sde-базе живут

хотя для полноты картины все-таки проверю, как будет работать с gdb из под ArcMap

2. у меня расширение ArcMap (со своей закладкой в TOC и прочими прелестями - не уверен, что это важно, но может и влияет), а не просто команда, вызываемая по кнопке

3. все это работает в немаленьком проекте - порядка сотни слоев из двух разных sde-баз, плюс еще куча shape-файлов и несколько mdb-баз
(хотя в своем модуле я пытаюсь загрузить только данные из одного слоя, лежащего в sde-базе)

4. может еще от версии зависеть - хотя, опять же не уверен.
ArcGIS Desktop у меня версии 9.2 SP5, а вот ArcSDE - 9.3.1 SP1

Answer 8

кстати, по ходу обнаружил еще такую вещь: код в том виде, как есть, отказался компиляться под VS2010 RC

Если сделать проект в 2008, потом открыть его в 2010RC и конвертнуть, то всё работает)
А если сразу в 2010 делать, то да, что-то 2010-й .net-сборки от esri не видит.

Там ещё мой косяк. Лишняя строчка, забыл убрать:
using ClassLibrary1.FeatureExtensions;
Сейчас исправлю.
    

Answer 9

-3A-, ну так и давайте посмотрим, отчего происходит снижение скорости на порядок. Из-за SDE вместо файловой базы, из-за закладки в TOC или из-за старой версии ArcGIS Desktop.
    

Answer 10

все оказалось гораздо проще
если вставить вызов Thread.Join - все начинает работать быстро
НО: основной поток при этом тормозится и ждет, пока закончится загрузка
а вот если Join не вызывать - получаем жуткие тормоза, независимо от базы и всего остального

мне от этого выгоды никакой: моя идея была в том, что пока при загрузке проекта модуль кэширует данные - пользователь может что-то делать - задать нужный масштаб, перейти к каким-то координатам, к примеру

а с Join я получаю обычное однопоточное поведение, даже еще и слегка заторможенное