Здравствуйте, Andrew S, Вы писали:
_>>>>2. Не могу согласиться. Да, если ресурс не может быть занят сразу, то в случае однопроцессорной машины спин-блокировки не происходит и сразу будет переход в режим ядра. Но, если ресурс свободен, то перехода в режим ядра не будет, потому как незачем. В таком случае имеем выигрыш.
AS>>>Спин-блокировка это совсем не то, что вы думаете. Быстрая проверка на занятость есть и для однопроцессорной критической секции, а спинлок — это совершенно другое. Почитайте еще вот тут — http://www.rsdn.ru/article/baseserv/critsec.xml
. _>>И тут почитаю тоже. _>>Вопрос вот в чем: если все-таки у однопроцессорной критической секции есть быстрая проверка на занятость, то не будет ли в случае незанятого ресурса захват критической секции быстрее, чем объекта ядра ? _>>Спасибо.
AS>Будет. Но тут говорилось про другое — предназначение спинлока в критической секции. Смысл в том, что на однопроцессорной машине он бесполезен (а точнее, вреден). Поэтому однопроцессорные и многопроцессорные машины помимо разных HAL имеют еще и как минимум разный native рантайм.
ОК. Резюмирую так:
1. Спин-блокировка на многопроцессорной машине дает преимущество, на однопроцессорной бесполезна.
2. Критические секции могут быть эффективнее объектов ядра как на многопроцессорных машинах, так и на однопроцессорных.
Согласны?
Здравствуйте, ZergIII, Вы писали:
ZII>Уважаемый, мы брейнбенч-подобные вопросы используем только для предварительной фильтрации и не требуем 100% правильных ответов. Просто экономия времени. Мне кажется, что если человек из 20 вопросов по С++ правильно отвечает только на 10 (причем уверяю вас, мы не задаем супер сложные вопросы или вопросы с подковырками) то это говорит либо о том, что он только недавно начал учить С++, либо (если у него опыт на С++ 5 лет), что его желание развиваться и поднимать свой технический уровень под большим вопросом.
К слову сказать, я вот сеньор.
Только.. ну, как бы сказать, чтобы не обидеть.
Контора, которая выдает браинбенч-подобные вопросы в лоб (не важно, для фильтрации ли или в каких других целях) моментально перемещается в мой собственный черный список.
Так что смотрите, как бы чего лишнего не "отфильтровать"
Здравствуйте, serg_joker, Вы писали:
_>Прикольно, но реализация sort, соответствующая стандарту, должна гарантировать сложность алгоритма n*log(n). Очевидно, что используя advance, таких гарантий дать нельзя. Кроме того, по стандарту sort таки требует RandomAccessIterator. См. ISO/IEC 14882:2003 — пп. 25.3.1.1
_>PS: Привет, Миша
Ради твоей регистрации можно было разводить провокаци !!! Даже Сергей. Л. появился
Привет!
A>>-чем функтор лучше функции (в частности, эффективнее ли) A>>-в каких случаях функцтор или функция не инлайнится?
DC>Хм.. Насколько я понимаю сильно от компилятора зависит. Кроме того это вроде как рекомендация компилятору, но функтор встроится вероятнее. Наличие >ссылок на функию может повлиять, хотя — хз я не разработчик компиляторов.
инлайн это такая необязательная штука, которую компилятор может выполнять, а может и нет.
например в VC++ целых три режима оптимизации, связанных только с инлайнами (+ __forceinline)
имхо такие вопросы стоит задавать только разработчикам компиляторов, если хотите услышать внятный ответ. у остальных ответ будет
носить характер домыслов
AS>>Будет. Но тут говорилось про другое — предназначение спинлока в критической секции. Смысл в том, что на однопроцессорной машине он бесполезен (а точнее, вреден). Поэтому однопроцессорные и многопроцессорные машины помимо разных HAL имеют еще и как минимум разный native рантайм. _>ОК. Резюмирую так: _>1. Спин-блокировка на многопроцессорной машине дает преимущество, на однопроцессорной бесполезна. _>2. Критические секции могут быть эффективнее объектов ядра как на многопроцессорных машинах, так и на однопроцессорных. _>Согласны?
Ну а кто другое говорил? Это очевидно любому, кто прочитал хотя бы Рихтера
Здравствуйте, Andrew S, Вы писали:
AS>>>Будет. Но тут говорилось про другое — предназначение спинлока в критической секции. Смысл в том, что на однопроцессорной машине он бесполезен (а точнее, вреден). Поэтому однопроцессорные и многопроцессорные машины помимо разных HAL имеют еще и как минимум разный native рантайм. _>>ОК. Резюмирую так: _>>1. Спин-блокировка на многопроцессорной машине дает преимущество, на однопроцессорной бесполезна. _>>2. Критические секции могут быть эффективнее объектов ядра как на многопроцессорных машинах, так и на однопроцессорных. _>>Согласны?
AS>Ну а кто другое говорил? Это очевидно любому, кто прочитал хотя бы Рихтера
Привожу цитату от постов выше по теме: CC>>А толку. В винде в критической секции используется семафор, который используется если критическая секция уже захвачена. >Но в начале могут быть спинлоки. Дает бонус на многопроцессорной машине
Лично у меня сложилось впечатление, что автор считает, что бонус от критической секции есть только на многопроцессорной машине. Возможно, я не правильно воспринял или автор не до конца высказал мысль.
Здравствуйте, AntZ, Вы писали:
A>>>-что такое синглтон (попросили написать код) A>>>-как избежать рейс кондишена при инициализации синглтона
DC>>Я бы ответил: не использовать сингтон . Уж лучше за собой через параметры функций таскать, чем иметь потом секс с трудноуловимой и трудно воспроизводимой ошибкой.
AZ>Это ответ из серии лечения перхоти при помощи гильотины. Очень помогает. Да элементарно, надо в MySingletonClass::GetInstance() встроить критическую секцию или мьютекс, после лока мьютекса проверять, а не создан ли уже объект в соседнем треде.
Понимаешь, мне еще толком не приходилось ковыряться с многозадачностью. Но тут есть 2 момента которые я точно знаю: 1. В С++ нет нормальных примитивов, они дай бог придут в С++х0; 2. Синглтон достаточно простой механизм и в некоторых случаях он не только решает поставленную задачу, но еще и создает море трудностей. Исходя из этого я делаю заключение, что использовать синглтона в многопоточной среде не самое хорошее архитектурное решение, мало того если еще это критично по скорости, то локи могут еще и не подойти.
A>>>пришлось объяснять про double-checked locking, A>>>попутно возникли вопросы про блокировку и мьютексы
AZ>Абсолютно логично, против рейсов помогают правильные локи.
Я в этой теме не очень, но знаю что тут надо бороться с компилятором, чтоб он не дай бог не переупорядочил операции в ходе оптимизаций.
DC>>Вот не пойму, каким боком качества управленца к сеньору . Такие вопросы ИМХО даже тим лида не особо беспокоят, это скорее уровень ПМа.
AZ>Ну, они очень любят играть игры в "Синьоров". Сеньер — это всего лишь слово, только некоторые вкладывают в него смысл, как обычный программер, только "в десять раз круче".
Да хоть в 30 раз, причем тут чисто управленческие качества? Это ведь к программированию не имеет никакого отношения. Это все равно что спросить как правильно построить выкройку и какую ткань лучше использовать для конкретной вещи. Ну что слабо ответить на эту тему? ИМХО это абсурд, этих вопросов можно было ожидать для ПМа, ну, накрайняк, для тимлида.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
> A>>>пришлось объяснять про double-checked locking, > A>>>попутно возникли вопросы про блокировку и мьютексы > > AZ>Абсолютно логично, против рейсов помогают правильные локи. > > Я в этой теме не очень, но знаю что тут надо бороться с компилятором, чтоб он не дай бог не переупорядочил операции в ходе оптимизаций.
Все гораздо хуже. Если инструкции не переупорядочил компилятор, это вполне может сделать процессор. Причем когда первый раз это проявится, будешь долго смотреть в отладчик и недоумевать, как оно в этом безобидном double-checked lock'е могло упасть
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Все гораздо хуже. Если инструкции не переупорядочил компилятор, это вполне может сделать процессор. Причем когда первый раз это проявится, будешь >долго смотреть в отладчик и недоумевать, как оно в этом безобидном double-checked lock'е могло упасть
переупорядочивание подавляется с помощью memory barriers
AS>>>>Будет. Но тут говорилось про другое — предназначение спинлока в критической секции. Смысл в том, что на однопроцессорной машине он бесполезен (а точнее, вреден). Поэтому однопроцессорные и многопроцессорные машины помимо разных HAL имеют еще и как минимум разный native рантайм. _>>>ОК. Резюмирую так: _>>>1. Спин-блокировка на многопроцессорной машине дает преимущество, на однопроцессорной бесполезна. _>>>2. Критические секции могут быть эффективнее объектов ядра как на многопроцессорных машинах, так и на однопроцессорных. _>>>Согласны?
AS>>Ну а кто другое говорил? Это очевидно любому, кто прочитал хотя бы Рихтера
_>Привожу цитату от постов выше по теме: CC>>>А толку. В винде в критической секции используется семафор, который используется если критическая секция уже захвачена. >>Но в начале могут быть спинлоки. Дает бонус на многопроцессорной машине _>Лично у меня сложилось впечатление, что автор считает, что бонус от критической секции есть только на многопроцессорной машине. Возможно, я не правильно воспринял или автор не до конца высказал мысль.
Именно в приведенной цитате очевидно, о чем говорится. Нужное выделено. Трактовать это как либо еще (и тем более уж где тут сравнение скорости критической секции и объекта ядра) — довольно сложно.
>S>Все гораздо хуже. Если инструкции не переупорядочил компилятор, это вполне может сделать процессор. Причем когда первый раз это проявится, будешь >долго смотреть в отладчик и недоумевать, как оно в этом безобидном double-checked lock'е могло упасть > > переупорядочивание подавляется с помощью memory barriers
Я вообще-то в курсе
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Andrew S, Вы писали:
AS>>>>>Будет. Но тут говорилось про другое — предназначение спинлока в критической секции. Смысл в том, что на однопроцессорной машине он бесполезен (а точнее, вреден). Поэтому однопроцессорные и многопроцессорные машины помимо разных HAL имеют еще и как минимум разный native рантайм. _>>>>ОК. Резюмирую так: _>>>>1. Спин-блокировка на многопроцессорной машине дает преимущество, на однопроцессорной бесполезна. _>>>>2. Критические секции могут быть эффективнее объектов ядра как на многопроцессорных машинах, так и на однопроцессорных. _>>>>Согласны?
AS>>>Ну а кто другое говорил? Это очевидно любому, кто прочитал хотя бы Рихтера
_>>Привожу цитату от постов выше по теме: CC>>>>А толку. В винде в критической секции используется семафор, который используется если критическая секция уже захвачена. >>>Но в начале могут быть спинлоки. Дает бонус на многопроцессорной машине _>>Лично у меня сложилось впечатление, что автор считает, что бонус от критической секции есть только на многопроцессорной машине. Возможно, я не правильно воспринял или автор не до конца высказал мысль.
AS>Именно в приведенной цитате очевидно, о чем говорится. Нужное выделено. Трактовать это как либо еще (и тем более уж где тут сравнение скорости критической секции и объекта ядра) — довольно сложно.
Прошу прощения, я был невнимателен.
Здравствуйте, Awaken, Вы писали:
A>Сходил в компанию, знаменитую своими сложными собеседованиями. A>надеюсь вопросы не могут являться тайной, иначе грош цена таким вопросам, A>если знание ответов заранее дает 100% прохождение собеседования A>итак, вопросы: A>C++ и STL: A>-чем отличаются list и vector A>-как отсортировать vector по убыванию A>написал код с функтором переопределяющим сравнение. A>дальше было вопрос A>-чем функтор лучше функции (в частности, эффективнее ли) A>-в каких случаях функцтор или функция не инлайнится? A>-как отсортировать список? A>-почему алгоритм sort не примениним к контейнеру list? A>Design patterns: A>-что такое синглтон (попросили написать код) A>-как избежать рейс кондишена при инициализации синглтона A>пришлось объяснять про double-checked locking, A>попутно возникли вопросы про блокировку и мьютексы A>-чем отличается критическая секция от мьютекса A>(это их любимый вопрос -я до сих пор НЕ ЗНАЮ, как внутри работает критическая секция, A>знаю только что она быстрее и ее нельзя шарить между процессами) A>-абстрактная фабрика, когда применять? попросили нарисовать UML диаграмму, A>и придумать пример из жизни. A>придумал кодогенератор генерирующий одни и те же конструкции на разных языках программирования : A>JavaFactory, CSharpFactory, CPlusFactory A>-паттерн композит, нарисуйте диаграмму A>-как реализовать глубокое копирование вышеуказанного паттерна, с помощью виртуального конструктора. A>здесь суть в том что возникает проблема с возможными циклическими ссылками на объекты, A>и нужно копировать все объекты только один раз. эту задачу я не решил за приемлимое время A>по моему тут нужно придумать что-то типа раскраски графа, чтоб отмечать вершины которые мы уже посетили. A>далее были вопросы по менеджерским качествам: A>-как организовать работу удаленных друг от друга команд A>-какое взаимодействие когда использовать (почта, телефон, IM) A>-как организовывать митинги, сколько времени тратить на обсуждения A>немного поговорили по английски (с этим у меня все ок, на программерские темы могу трындеть сколько угодно, A>да и просто "о жизни" тоже) A>итог — я похоже не очень удовлетворил их ожидания. а мне в свою очередь не очень понравилось содержание работы. A>на том мы и расстались.
ну вот.. в контору взяли — а там шум, рабочие всякие шастают, верно?
ирония судьбы, не иначе.
Здравствуйте, ZergIII, Вы писали:
ZII>Wow, прикольно почитать какое у нас сложное собеседование ZII>А что вы хотели на позицию Senior C++ Developer?
странно и нелогично выглядит появление здесь работодателя, с заявлениями в таком тоне (видно, как вы относитесь к людям в частности).
уж чего, а популярности это никак вам не добавит.
. Такие вопросы ИМХО даже тим лида не особо беспокоят, это скорее уровень ПМа.
ИМХО это абсурд, этих вопросов можно было ожидать для ПМа, ну, накрайняк, для тимлида.
