Здравствуйте!

Есть поток messageThread с очередью(FIFO) сообщений, которые обрабатываются и удаляются из очереди.
В гуи надо показать все сообщения из этой очереди (допустим в листбоксе показать названия сообщений).
Гуи в другом потоке — guiThread.
Сообщения в очередь messageThread постоянно добавляются и удаляются. Можно также
удалить сообщение из середины очереди с помощью гуи: выделить в листбоксе строку и нажать "удалить".

Как бы минимизировать время обновления гуи при изменении очереди, чтобы поток messageThread,
где соообщения обрабатываются, блокировался на минимальное время?

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

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

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

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

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

K>Здравствуйте, игппук, Вы писали:

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

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

Как вариант: Если требования к памяти некритичны и копирование элементов очереди — быстрая операция, то можно просто скопировать очередь в другую временную, которую затем отобразить на экране. При копировании, естественно, блокировать основную очередь на запись.

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

K>Есть поток messageThread с очередью(FIFO) сообщений, которые обрабатываются и удаляются из очереди.
K>В гуи надо показать все сообщения из этой очереди (допустим в листбоксе показать названия сообщений).
K>Гуи в другом потоке — guiThread.
K>Сообщения в очередь messageThread постоянно добавляются и удаляются. Можно также
K>удалить сообщение из середины очереди с помощью гуи: выделить в листбоксе строку и нажать "удалить".

Кем добавляются, кем удаляются, как часто? Без контекста сложно ответить.

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

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

K>>Есть поток messageThread с очередью(FIFO) сообщений, которые обрабатываются и удаляются из очереди.
K>>В гуи надо показать все сообщения из этой очереди (допустим в листбоксе показать названия сообщений).
K>>Гуи в другом потоке — guiThread.
K>>Сообщения в очередь messageThread постоянно добавляются и удаляются. Можно также
K>>удалить сообщение из середины очереди с помощью гуи: выделить в листбоксе строку и нажать "удалить".

RO>Кем добавляются, кем удаляются, как часто? Без контекста сложно ответить.

Добавляются пользователем с помощью гуи, а также могут формироваться без участия пользователя(автоматически)
сразу большой охапкой.

Удаляются пользователем с помощью гуи, а также самой программой после обработки

В моем случае пока не часто, точнее нет большой нагрузки на обработчик команд. Но я просто задумался
для образования, как это реализуется если бы была большая нагрузка и время жизни команды от создания до
обработки(удаления), было бы таким, чтобы пользователь её смог увидеть в очереди, выделить и отменить.

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

K>Здравствуйте!

K>Есть поток messageThread с очередью(FIFO) сообщений, которые обрабатываются и удаляются из очереди.
K>В гуи надо показать все сообщения из этой очереди (допустим в листбоксе показать названия сообщений).
K>Гуи в другом потоке — guiThread.
K>Сообщения в очередь messageThread постоянно добавляются и удаляются. Можно также
K>удалить сообщение из середины очереди с помощью гуи: выделить в листбоксе строку и нажать "удалить".

K>Как бы минимизировать время обновления гуи при изменении очереди, чтобы поток messageThread,
K>где соообщения обрабатываются, блокировался на минимальное время?

Как вариант — создать отдельную очередь специально для гуи. В нее складывать события об изменении очереди в messageThread. По таймеру забирать накопившуюся информацию (можно тупо менять два указателя — первый куда очередь складывается — второй откуда очередь берется), но перед тем как выкидывать ее в гуи — предобработать: обработать эту очередь в памяти (ну то есть выполнить все операции добавления и удаления), в результате получить готовый небольшой списочек — который и выбросить в гуи listbox. В результате основные функции будут выполняться до того, как отобразиться на экране — то есть нагрузка на гуи будет небольшой. Плюс блокирование будет происходить только для простой операции замены указателей — совсем чуть-чуть.

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

K>В моем случае пока не часто, точнее нет большой нагрузки на обработчик команд. Но я просто задумался
K>для образования, как это реализуется если бы была большая нагрузка и время жизни команды от создания до
K>обработки(удаления), было бы таким, чтобы пользователь её смог увидеть в очереди, выделить и отменить.

Вот выделенное как-то слабо сочетается. Я подозреваю, что для твоих нужд вполне хватит одного простого mutex’а.

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

K>Как бы минимизировать время обновления гуи при изменении очереди, чтобы поток messageThread,
K>где соообщения обрабатываются, блокировался на минимальное время?

Можно сделать следующее:
— в messageThread держать коллекцию
— в guiThread — держать зеркало этой коллекции
— между потоками — канал связи с минимальной латентностью (lock-free, если уж совсем припрёт)

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

Каждый раз, когда guiThread собирается внести изменение, он посылает сообщение об этих планах messageThread'у и либо сразу меняет зеракло, либо честно дожидается, когда messageThread пришлёт сообщение (см. выше).

Примерно так работают почтовые клиенты с серверами по протоколу IMAP
В зависимости от наворотов задачи, может потребоваться уникальная идентификация каждого элемента коллекции, а не только нумерация по индексу.
Если критично, чтобы зеркало всегда точно отражало оригинал, то поток UI должен блокировать ввод пользователя всякий раз, как только в канале связи есть необработанные сообщения.

...
А еще можно разбить коллекцию на страницы и блокировать каждую страницу независимо.

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

К>Примерно так работают почтовые клиенты с серверами по протоколу IMAP
Правильно говорят, что любая многопоточная система содержит в себе частичную и глючную реализацию Erlang'а