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

Question

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

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

• App имеет в списках памяти данных, lišta, LISTB
• App имеет локальную копию данных (для автономной функциональности) dataFileA, dataFileB
• App имеет резьбу ТА1, ТВ1, который обновление грязных данных от клиента к серверу
• Тема tA2, обновление tB2 грязных данные от сервера к клиенту
• Тема tA3, обновление ТВ3 грязных данные в списках памяти для локальных файлов

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

Вот некоторые цели я изобретенные для себя:

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

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

Answer 1

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

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

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

Надеется, что это помогает.

Answer 2

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

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

Если потоки (UI и фасад) ждут друг друга, чтобы завершить их запросы, тогда это должно помешать «обновлению выталкивания» одновременно с «push update».

Answer 3

Для осуществления таких изменений в целом вам нужно будет взглянуть на Refactoring: Improving the Design of Existing Code Мартина Фаулера (большая часть из которых находится на the refactoring website), а также Refactoring to Patterns.Вы также можете найти Working Effectively with Legacy Code, что полезно для поддержки безопасных изменений. Ничто из этого не имеет особого рода помощь в многопоточности, за исключением того, что более простой код легче обрабатывать в многопоточной среде.

Answer 4

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