Симон Моурир дал этот пример :
object o = null;
DateTime d = (DateTime)o; // NullReferenceException
, где unboxing преобразование (литье) из object
(или из одного из классов System.ValueType
или System.Enum
или из типа интерфейса) - тип значения (кроме Nullable<>
) сам по себе дает NullReferenceException
.
В другом направлении конверсия бокса из a Nullable<>
, которая имеет HasValue
, равную false
, на ссылочный тип, может дать ссылку null
, которая затем может привести к NullReferenceException
. Классический пример:
DateTime? d = null;
var s = d.ToString(); // OK, no exception (no boxing), returns ""
var t = d.GetType(); // Bang! d is boxed, NullReferenceException
Иногда бокс происходит по-другому. Например, с помощью этого не общего метода расширения:
public static void MyExtension(this object x)
{
x.ToString();
}
следующий код будет проблематичным:
DateTime? d = null;
d.MyExtension(); // Leads to boxing, NullReferenceException occurs inside the body of the called method, not here.
Эти случаи возникают из-за специальных правил, используемых во время выполнения при боксе Nullable<>
экземпляров.
caf, в вашем примере кода Process B изменяет condition
без блокировки мьютекса в первую очередь. Если Process B просто заблокировал мьютекс во время этой модификации, а затем все еще разблокировал мьютекс перед вызовом pthread_cond_signal
, не было бы проблем --- я прав об этом?
Я считаю, что интуитивно, что position верно: вызов pthread_cond_signal
без владения блокировкой мьютекса - это плохая идея. Но пример в кафе на самом деле не является доказательством в поддержку этой позиции; это просто доказательство в пользу гораздо более слабой (практически очевидной) позиции, что Bad Idea модифицирует разделяемое состояние, защищенное мьютексом, если вы не заблокировали этот мьютекс в первую очередь.
Может ли кто-нибудь предоставить образец код, в котором вызов pthread_cond_signal
, за которым следует pthread_mutex_unlock
, дает правильное поведение, но вызов pthread_mutex_unlock
, а затем pthread_cond_signal
дает неправильное поведение?
В соответствии с этим руководством:
Функции
blockquote>pthread_cond_broadcast()
илиpthread_cond_signal()
могут вызываться потоком независимо от того, владеет ли он в настоящее время мьютексом, который потоки, вызывающиеpthread_cond_wait()
илиpthread_cond_timedwait()
связаны с переменной условия во время их ожидания; однако, если требуется предсказуемое поведение планирования, то мьютекс должен быть заблокирован потоковым вызовомpthread_cond_broadcast()
илиpthread_cond_signal()
.Значение предсказуемого поведения планирования объяснил Дейв Бутенхоф (автор Программирование с потоками POSIX ) на comp.programming.threads и доступен здесь .