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

SC>И вот собственно темы, на которые Вы можете подумать перед сном:
SC>1. Представьте себе облако, в котором, скажем, 10000 серверов. Облако работает исправно, решая поставленные задачи. Вы — программист — Bing.AdCenter, и написали новую версию функции (про которую тут язвили) — strcmp. И вот, вам нужно обновить strcmp.dll на обозначенном облаке. Никто не ждет от Вас конкретного решения — просто поделитесь своими соображениями. Это реальная задача, в которой нужно понимать все сложности возникающие в этом процессе. Насколько глубоко Вы сможете погрузиться?

Для начала рассылаем библиотеку по всем серверам с другим именем.
А дальше -It depends.
Надо обеспечить максимальную скорость обновления или максимальный thoroughput облака?
Если первое, то глушим все сервера, кроме одного, удаляем старую-переименовываем новую библиотеку в старую, перезапускаем все остановленные сервера.
Если второе, то повторяем предыдущий шаг, но N останавливаемых серверов в каждый момент времени =1.
Если достичь баланса между скоростью обновления и производительностью — N= M\2, где M=количество серверов.

В этой задаче есть куда погрузиться глубже?

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

SA>Не помню точно Рихтера по этому вопросу, но, КМК, критические секции над Interlocked и реализованы .
SA>Стоит ли выигрыш в пару тактов процессора усложнения и размазывания логики, которое возникает при использовании InterlockedCompare|Exchange в сравнении с критической секцией?

Если мы говорим о Win32, то при одиночном (non-contended) доступе все ограничится несколькими амтомарными операциями, да. Но если секция занята, то поток уйдет из юзер-мода в кернел-мод (возможно сначала отработав спин-каунт если есть), а это уже стоит дорого. Преимущество интерлоков как раз в том, что они всегда выполняются в юзер-моде и всегда за конечное число шагов.

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

A>Если мы говорим о Win32, то при одиночном (non-contended) доступе все ограничится несколькими амтомарными операциями, да. Но если секция занята, то поток уйдет из юзер-мода в кернел-мод (возможно сначала отработав спин-каунт если есть), а это уже стоит дорого. Преимущество интерлоков как раз в том, что они всегда выполняются в юзер-моде и всегда за конечное число шагов.

Всегда считал критическую секцию легковесным объектом юзер-мода.
Встречаю уже второе упоминание, что она может использовать ядро..хм.
Ну ок, возможно.
Дальше по задаче — скорректировать head\tail InterlockedCompare | Exchange легко и непринужденно. А redimension с сохранением предыдущего состояния?
Тоже на атомарных операциях выполнять?

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

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

A>>конечно перфоманс, стоимость инициализации/освобождения мьютекса (объекта ядра) несравнима с атомарными операциями, выполняющимися напрямую на процессоре. Даже в случае с критическими секциями, если очередь/стек используется тяжело, и идут тысячи push/pop в секунду, оверхед будет большим.
A>>Конечно, мьютексы — универсальное решение, но это не значит что оно оптимально. Поинтеры-то мы можем перекинуть без локов.

THE>>>[skip]

SA>Не помню точно Рихтера по этому вопросу, но, КМК, критические секции над Interlocked и реализованы .
SA>Стоит ли выигрыш в пару тактов процессора усложнения и размазывания логики, которое возникает при использовании InterlockedCompare|Exchange в сравнении с критической секцией?

при неудачном захвате уходим в kernel mode. там не пара тактов

Мне кажется, что вопрос не в том, как лучше всего решить задачу, а как решить ее предоставленными средствами. То есть исходные параметры очень четко определены. Есть синхронизируемая коллекция, есть атомарные операции. Осталось сложить все вместе, и получить результат. Идеально при этом вспомнить про имеющиеся в ОС инструменты синхронизации и подискутировать, что лучше.

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

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

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

S>>>индус?

TB>>Таки ви расист?

S>почему? просто спросил для статистики

Ааа, тогда другое дело. Я, честно говоря, этого не знаю, и спрашивать во время разговора будет неудобно. Википедия, впрочем, говорит: Sitaram means Sita and Rama. It is one of the Indian names.

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

A>Преимущество интерлоков как раз в том, что они всегда выполняются в юзер-моде и всегда за конечное число шагов.
За конечное, но возможно за очень большое число шагов.

Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, anomander, Вы писали:
A>>Преимущество интерлоков как раз в том, что они всегда выполняются в юзер-моде и всегда за конечное число шагов.
AJD>За конечное, но возможно за очень большое число шагов.
навскидку в среднем это число шагов равно кол-ву потоков пытающихся совершить эту операцию пополам. то есть даже для сотни потоков это число маленькое. в то время как обьекты ведра стопорят всю сотню потоков с неизвестным и системнозависимым троллингом. короче говоря, именно за интерлокедами будущее

Здравствуйте, __kot2, Вы писали:
__>короче говоря, именно за интерлокедами будущее
хотя вообще-то в GPGPU, как самой честной многопоточности, синхронизация выполняется только барьерами и другого варианта в обозримом будущем не предвидится