Стратегии для многопоточного приложения

Question

Я мог бы унаследовать несколько сложное многопоточное приложение, в котором в настоящее время есть несколько файлов с 2 + k loc, множество глобальных переменных, доступ к которым есть везде, и другие методы, которые я бы посчитал довольно вонючим.

Прежде чем я начну добавлять новые функции с текущими шаблонами, я хотел бы попытаться выяснить, могу ли я улучшить базовую архитектуру приложения. Вот краткое описание:

• Приложение имеет в памяти списки данных, listA, listB
• Приложение имеет локальную копию данных (для автономной работы) dataFileA, dataFileB
• Приложение имеет потоки tA1, tB1, которые обновляют грязные данные с клиента на сервер
• Потоки tA2, tB2 обновляют грязные данные с сервера на клиент
• Потоки tA3, tB3 обновляют грязные данные из списков памяти в локальные файлы

У меня какие-то проблемы с тем, какие шаблоны, стратегии, методы программирования и т. Д. Мне следует изучить, чтобы иметь знания для принятия лучших решений по этому вопросу.

Вот некоторые цели, которые я придумал для себя:

1. Держите приложение максимально стабильным
2. Облегчить для Generic Intern добавление новых функций (большие нет-нет до 50 строк стандартного кода в каждом новом EditRecordX.cs)
3. Уменьшить сложность

Спасибо за любые ключевые слова или другие советы, которые могут помочь мне в этом проекте.

Answer 1

К отличным предложениям Quibblesome я также могу добавить, что использование неизменяемых объектов часто является эффективным способом снижения риска проблем с многопоточностью. (Неизменяемые объекты, такие как строки в .NET и Java, не могут быть изменены после их создания.)

Answer 2

Я бы предложил еще одну цель: удалить / уменьшить глобальное состояние и как можно чаще хранить информацию в стеке, чтобы уменьшить вероятность возникновения состояний гонки и странных проблем с многопоточностью.

Возможно, стоит посмотреть, можете ли вы включить tA2, tB2, tA3 и tB3 в одни и те же потоки, чтобы убить нескольких. Если это невозможно, рассмотрите возможность их размещения за фасадом (поток, который занимается перемещением запросов данных между пользовательским интерфейсом и службой, взаимодействующей с сервером). Таким образом, «пользовательский» код имеет дело только с одним клиентом, а не с двумя. (Я не считаю резервную копию клиентом, поскольку это звучит как односторонний процесс).

Если потоки (пользовательский интерфейс и фасад) ждут друг друга, чтобы завершить свои запросы, это должно предотвратить "извлечение обновлений" одновременно с "принудительным обновлением".

Answer 3

Для внесения такого рода изменений в целом вам нужно взглянуть на Рефакторинг Мартина Фаулера: Улучшение дизайна существующего кода (большая часть которого находится на сайте рефакторинга ) и также Рефакторинг к паттернам . Вам также может пригодиться Эффективная работа с устаревшим кодом для поддержки безопасных изменений. Ничто из этого не особенно помогает в многопоточности, за исключением того, что более простой код легче обрабатывать в среде многопоточности.

Answer 4

Я думаю, вы должны взглянуть на это: http://msdn.microsoft.com/en-us/concurrency/default.aspx

И эта запись в блоге: http://blogs.msdn.com/pfxteam/

А это: http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx

Надеюсь, это поможет.