Здравствуйте, BioUnit, Вы писали:

BU>Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь.

Не "своеобразная очередь" а просто очередь. То что вы описали — классическая задача "читатели-писатели" с одним разделяемым ресурсом — очередью. Давно решена и описана в книжках по операционным системам. Смотрите из современных Таненбаум "Современные операционные системы" — серия "Классика computer science" или Столлингс "Операционные системы". Там она детально описана с использованием семафоров, но можно использовать и mutex в Win32

Здравствуйте, <Аноним>, Вы писали:

ДН>>В случае списка, во избежание падения перфоманса, можно лочить только три элемента — тот который удаляется/вставляется и два его соседа. К остальным элементам доступ на чтение в это время можно разрешать.

А>как это предполагается реализовать технически?

А в чем проблема? Никаких трудностей не вижу...

Павел, подскажите пожалуйста, вот например я отправил сообщение, потом смотрю там, например, ошибка, опечатка, не дописал что то, или просто избыточное цитирование забыл удалить (как в моем случае) — какие у меня есть возможности исправить? Модерирование вроде позволяет только убить сообщение...

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН> Павел, подскажите пожалуйста, вот например я отправил сообщение,
ДН> потом смотрю там, например, ошибка, опечатка, не дописал что то, или
ДН> просто избыточное цитирование забыл удалить (как в моем случае) -
ДН> какие у меня есть возможности исправить?

К сожалению, в настоящий момент редактирование сообщений доступно только
модераторам. Тем не менее, возможность внести исправления в собственное
сообщение имеется: достаточно написать на
с обязательным указанием ссылки на сообщение и желаемых изменений,
либо же ответить на собственное сообщение с указанием необходимых исправлений.

В случае запроса через кто-нибудь из
модераторов внесет исправления, как только позволит время; пользоваться
этой возможностью следует, если допущена грубая ошибка, требующая скорейшего
исправления.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ДН>> избыточное цитирование забыл удалить

P.S. В случае избыточного цитирования наиболее подходящими вариантами
являются удаление собственного сообщения ("удалить как ошибочное")
с последующим размещением исправленного варианта, либо же письмо на
. С другой стороны, в большинстве случаев, избыточное
цитирование не является проблемой, требующей срочного вмешательства, и, скорее
всего, модератор и без этого поправит его при очередном просмотре форума.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>С другой стороны, в большинстве случаев, избыточное
ПК>цитирование не является проблемой, требующей срочного вмешательства, и, скорее
ПК>всего, модератор и без этого поправит его при очередном просмотре форума.

Он то поправит... с вынесением предупреждения и лишением сладкого...

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН> Он то поправит... с вынесением предупреждения и лишением сладкого...

Тогда пиши в
Гарантирую: никаких предупреждений и лишения сладкого не будет.

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>В случае списка, во избежание падения перфоманса, можно лочить только три элемента — тот который удаляется/вставляется и два его соседа. К остальным элементам доступ на чтение в это время можно разрешать.

А>как это предполагается реализовать технически?

ДН>А в чем проблема? Никаких трудностей не вижу...

не понимаю я, как одновременно залочить ровно три эл-та из произвольного множества. может объяснишь?
если лочить их не одновременно, получишь потенциальный дедлок.

Здравствуйте, <Аноним>, Вы писали:

А>не понимаю я, как одновременно залочить ровно три эл-та из произвольного множества. может объяснишь?
А>если лочить их не одновременно, получишь потенциальный дедлок.

Если лочить их везде в одном порядке, то никакого дедлока не будет.

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>А в чем проблема? Никаких трудностей не вижу...

Ну как же? Как проверять факт блокировки именно этих трех элементов? Для большинства приложений будет совершенно неадекватная "организационная" нагрузка. На нее можно пойти лишь если время блокировки значительно.

Здравствуйте, Михаил Можаев, Вы писали:

ММ>Здравствуйте, <Аноним>, Вы писали:

А>не понимаю я, как одновременно залочить ровно три эл-та из произвольного множества. может объяснишь?
А>если лочить их не одновременно, получишь потенциальный дедлок.

ММ>Если лочить их везде в одном порядке, то никакого дедлока не будет.

у тебя есть куча тредов, вставляющих эл-ты в список. как они должны лочить нужные им эл-ты, чтобы избежать дедлоков?

Здравствуйте, <Аноним>, Вы писали:

ММ>>Если лочить их везде в одном порядке, то никакого дедлока не будет.
А>у тебя есть куча тредов, вставляющих эл-ты в список. как они должны лочить нужные им эл-ты, чтобы избежать дедлоков?

Если эти потоки меняют состав множества, то, думаю, не получится.
Если бы состав множества (кол-во и порядок элементов в нем) не менялся, то все было бы просто.
Я имел в виду именно второй случай.