Статический функциональный параллелизм ASP.NET
попробуйте это:
echo '<form action="like.php?post_id=' . $post_id . '" method="POST">
<input type="submit" class="comment_like1" name="like_button" value="Like">
<div class="like_value">
'. $total_likes .' <i class="fa fa-thumbs-up"></i>
</div>
</form>'
7 ответов
Да, существует риск параллелизма при изменении статической переменной в статических методах.
Сами статические функции имеют отличные наборы локальных переменных, но любые статические переменные совместно используются.
В Ваших определенных образцах Вы не подвергаетесь, но это просто, потому что Вы используете константы (и присваиваете те же значения им). Измените пример кода немного, и Вы будете подвергнуты.
Править:
При вызове обоих Sum1 () И Sum2 () от различных потоков, Вы в беде, нет никакого способа гарантировать значение a и b в этом операторе: интервал c = + b;
private static int a = 5;
public static int Sum1()
{
int b = 4;
a = 9;
int c = a + b;
return c;
}
public static int Sum2()
{
int b = 4;
int c = a + b;
return c;
}
Можно также достигнуть проблем параллелизма с несколькими вызовами отдельного метода как это:
public static int Sum3(int currentA)
{
a = currentA;
int b = 4;
int c = a + b;
int d = a * b; // a may have changed here
return c + d;
}
Проблема здесь - то, что значение может изменить середину метода из-за других вызовов, изменяющих его.
Посмотрите здесь для обсуждения локальных переменных. перед Вашим редактированием ни один из самих вышеупомянутых методов не представил риск параллелизма; локальные переменные являются всем независимым политиком на вызов; общее состояние (static int a) видимо к нескольким потокам, но Вы не видоизменяете его, и Вы только читаете его однажды.
Если Вы сделали что-то как:
if(a > 5) {
Console.WriteLine(a + " is greater than 5");
} // could write "1 is greater than 5"
это было бы (в теории) не быть безопасным как значение можения быть измененным другим потоком - Вы будете обычно или синхронизировать доступ (через lock и т.д.), или берут снимок:
int tmp = a;
if(tmp > 5) {
Console.WriteLine(tmp + " is greater than 5");
}
При редактировании значения Вы почти наверняка потребовали бы синхронизации.
В Ваших двух примерах нет никаких проблем потокобезопасности, потому что каждый вызов к функции будет иметь свою собственную копию локальных переменных на стеке, и в Вашем первом примере с существом статическая переменная, Вы никогда не изменяетесь, таким образом, нет никакой проблемы.
При изменении значения в в первом примере, у Вас будет потенциальная проблема параллелизма.
Да, существует риск. Вот почему Вы будете видеть в документе MSDN, он будет часто говорить, что "Этот класс ориентирован на многопотоковое исполнение для статических участников" (или что-то как этот). Это означает, когда MS написал код, они намеренно использовали примитивы синхронизации для создания статических участников ориентированными на многопотоковое исполнение. Это распространено при записи библиотек и платформ, потому что легче сделать статических участников ориентированными на многопотоковое исполнение, чем члены экземпляра, потому что Вы не знаете то, что пользователь библиотеки собирается хотеть сделать с экземплярами. Если бы они сделали членов экземпляра ориентированными на многопотоковое исполнение для многих классов библиотеки, то они поместили бы слишком много ограничений на Вас... так часто они позволяют Вам обработать его.
Таким образом, аналогично необходимо сделать статических участников ориентированными на многопотоковое исполнение (или документ, что они не).
Между прочим, статические конструкторы ориентированы на многопотоковое исполнение в некотором смысле. CLR удостоверится, что их называют только однажды и будут препятствовать тому, чтобы 2 потока вошли в статического конструктора.
Править: Marc указал в комментариях на пограничный случай, в котором статические конструкторы не ориентированы на многопотоковое исполнение. При использовании отражения для явного вызова статического конструктора, по-видимому, можно назвать его несколько раз. Таким образом, я пересматриваю оператор следующим образом: пока Вы полагаетесь на CLR для решения, когда вызвать статического конструктора, затем CLR будет препятствовать тому, чтобы он был назван несколько раз, и он будет также препятствовать тому, чтобы статический ctor был назван повторно используемо.
Если объем переменных содержится в статической функции затем нет никакого риска, но переменных за пределами функционального объема (статичный / совместно использованный), DEFINITLY представляют угрозу параллелизма
Вы помещаете "ASP.NET" в заголовок вопроса, это сообщение в блоге является хорошей сводкой проблем при использовании ключевого слова ThreadStatic в ASP.NET: http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
Статические методы в OO не являются никаким различием от "просто" функций в процедурном программировании. Если Вы не храните некоторое состояние в статической переменной нет никакого риска вообще.