Ну, это, McCready does have a point. But so does Eric.
Но обсуждают они на самом деле совершенно разные вещи.
Эрик говорит про _обычную_ queue (например). У которой есть методы Enqueue, Dequeue, IsEmpty и всё такое. Его поинт состоит в том, что делать _эту_ очередь thread safe совершенно бессмысленно. И он совершенно прав.
Второй чувак говорит про особую очередь, разработанную специально для синхронизации. У неё нет проперти IsEmpty, зато есть методы TryDequeue, Dequeue(TimeSpan timeout) и другие. Возможно даже специальный блокирующийся Enqueue и возможность установить MaxCapacity.
Это совсем другой, высокоуровневый класс, который действительно предоставляет useful methods for inter-thread communication. Этот класс следует рассматривать рядом с такими классами как Mutex, например, а не рядом со стандартной очередью. Вот как ты считаешь, можно ли к классу Mutex осмысленно применить прилагательное thread-safe? Я считаю, что нет, оно там по дефолту подразумевается, а сам он реализует гораздо более мощную абстракцию, которую этим же словом называть наверное не следует всё-таки.
Ещё раз: имеется более или менее техническое определение thread safety, означающее что очередь или хэштейбл или что-нибудь ещё "has defined behaviour, and that behaviour is defined to be inconsistent and timing-dependent" (в случае обычной очереди или хэштейбла). И есть другое, гораздо более мощное и полезное понятие/свойство, описывающее в том числе и предоставляемый интерфейс, "inter-thread communication primitive". Более того, гипотетическая System.Threading.SynchronizedQueue на самом деле является довольно-таки outstanding в этом смысле, потому что действительно обычно не требует никаких дополнительных телодвижений, тогда как представить в такой же степени удобный SynchronizedDictionary мне уже тяжело, то есть понятно, что он должен параметризоваться типом лока, ожидаемой капасити (чтобы лочить только часть внутренних массивов) етс, но вот должен ли у него быть оператор this[]? Должен ли он поддерживать IEnumerable (наверняка нет)? етс.
Да, кажется, Эрик, когда писал свой пост и отвечал на первые два коммента Роба, о подобных высокоуровневых классах не задумывался. Впрочем, и сам Роб got to the point только в третьем комменте.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2009-12-03 09:17 pm (UTC)Ну, это, McCready does have a point. But so does Eric.
Но обсуждают они на самом деле совершенно разные вещи.
Эрик говорит про _обычную_ queue (например). У которой есть методы Enqueue, Dequeue, IsEmpty и всё такое. Его поинт состоит в том, что делать _эту_ очередь thread safe совершенно бессмысленно. И он совершенно прав.
Второй чувак говорит про особую очередь, разработанную специально для синхронизации. У неё нет проперти IsEmpty, зато есть методы TryDequeue, Dequeue(TimeSpan timeout) и другие. Возможно даже специальный блокирующийся Enqueue и возможность установить MaxCapacity.
Это совсем другой, высокоуровневый класс, который действительно предоставляет useful methods for inter-thread communication. Этот класс следует рассматривать рядом с такими классами как Mutex, например, а не рядом со стандартной очередью. Вот как ты считаешь, можно ли к классу Mutex осмысленно применить прилагательное thread-safe? Я считаю, что нет, оно там по дефолту подразумевается, а сам он реализует гораздо более мощную абстракцию, которую этим же словом называть наверное не следует всё-таки.
Ещё раз: имеется более или менее техническое определение thread safety, означающее что очередь или хэштейбл или что-нибудь ещё "has defined behaviour, and that behaviour is defined to be inconsistent and timing-dependent" (в случае обычной очереди или хэштейбла). И есть другое, гораздо более мощное и полезное понятие/свойство, описывающее в том числе и предоставляемый интерфейс, "inter-thread communication primitive". Более того, гипотетическая System.Threading.SynchronizedQueue на самом деле является довольно-таки outstanding в этом смысле, потому что действительно обычно не требует никаких дополнительных телодвижений, тогда как представить в такой же степени удобный SynchronizedDictionary мне уже тяжело, то есть понятно, что он должен параметризоваться типом лока, ожидаемой капасити (чтобы лочить только часть внутренних массивов) етс, но вот должен ли у него быть оператор this[]? Должен ли он поддерживать IEnumerable (наверняка нет)? етс.
Да, кажется, Эрик, когда писал свой пост и отвечал на первые два коммента Роба, о подобных высокоуровневых классах не задумывался. Впрочем, и сам Роб got to the point только в третьем комменте.