Как использовать AppDomain для ограничения объема статического класса для ориентированного на многопотоковое исполнение использования?
Это мое решение:
var a = "text :Array Item : {info.inner.interest[0]}";
replaceThis = "info.inner.interest[0]";
outPut = a.replace(replaceThis, 'hello me!!');
console.log(outPut);6 ответов
Используя домены приложения Вы могли сделать что-то вроде этого:
public class Loader
{
private string connectionString;
private string fileName;
private Stream stream;
private DataFile dataFile;
public Loader(Stream stream, string fileName, string connectionString)
{
this.connectionString = connectionString;
this.fileName = fileName;
this.stream = stream;
}
public void Process()
{
//***** Create AppDomain HERE *****
string threadID = Thread.CurrentThread.ManagedThreadId.ToString();
AppDomain appDomain = AppDomain.CreateDomain(threadID);
DataFile dataFile =
(DataFile) appDomain.CreateInstanceAndUnwrap(
"<DataFile AssemblyName>",
"DataFile",
true,
BindingFlags.Default,
null,
new object[]
{
aredstream,
filename,
connectionString
},
null,
null,
null);
dataFile.ParseFile();
dataFile.Save();
appDomain.Unload(threadID);
}
}
То, которое укусило, точно, является болью с точки зрения потокобезопасности? Я не вижу статического состояния, ни одиночных элементов - и, кажется, существуют соответствующие "новые" объекты... я являющийся слепым?
Таким образом, что является признаком, Вы видите...
Ответ AppDomain будет (относительно) медленным. Как часть поддержанной промежуточным программным обеспечением системы это могло бы быть в порядке (т.е. "относительно" находится на той же приблизительной оценке).
Если у Вас действительно есть некоторое статическое состояние где-нибудь, другая опция, которая иногда работает, [ThreadStatic] - который интерпретирует время выполнения, поскольку "это статическое поле уникально на поток". Необходимо быть осторожными с инициализацией, хотя - статический конструктор на потоке A мог бы присвоить поле, но затем распараллелить B, будет видеть null/0/etc.
Почему не только помещает блокировку вокруг кода, который Вы хотите выполнить последовательно? Это будет узкое место, но это должно работать в многопоточной среде.
public class Loader
{
private static object SyncRoot = new object();
private string connectionString;
private string fileName;
private Stream stream;
private DataFile dataFile;
public Loader(Stream stream, string fileName, string connectionString)
{
this.connectionString = connectionString;
this.fileName = fileName;
this.stream = stream;
}
public void Process()
{
lock(SyncRoot) {
dataFile = new DataFile(aredStream, fileName, connectionString);
dataFile.ParseFile();
dataFile.Save();
}
}
}
При совместном использовании помех, которые конфликтуют друг с другом, то Вы могли бы хотеть попытаться добавить [ThreadStatic] приписывают им. Это сделает их локальными для каждого потока. Это может решить Вашу проблему в ближайшей перспективе. Правильное решение состояло бы в том, чтобы просто повторно спроектировать Ваш материал, чтобы быть ориентированным на многопотоковое исполнение.
Только для полноты.
Я действительно находил, что, если я отметил отправить адаптер как "Заказанную Доставку" в "Транспортных Расширенных настройках" диалоговое окно, я смог избежать проблем мультипотока, которые я имел.
Я полагаю, что это - другое возможное решение моей проблемы, но не обязательно к вопросу.
При создании и разъединении appdomain для каждого вызова - я беру его, Вы не волнуетесь по поводу производительности на этом?
Идеально необходимо изменить названный код, чтобы быть ориентированными на многопотоковое исполнение.