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

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

Да вроде Рихтера перечитать, освежить и достаточно.

A_N>А ктонить может подбросить задач и вопросов с собеседований про это все? Есть какие-либо "стандартные" задачи на это дело (ну как про круглые люки)?
A_N>Для примера: на первом собеседовании меня пока попросили написать синхронизированную очередь.

Меня просили как-то написать ридер-райтер лок при условии, что в наличии есть только такой объект синхронизации, который можно или захватить или освободить. Узнать, захвачен ли объект, нельзя. Вроде правильно вспомни.

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

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

S>>Простой вопрос: поддержка целостности объекта через счетчик ссылок как в COM-t. Написать методы AddRef, Release.

A_N>Обычно приводят что-то такое:

Верно.
Здесь можно продолжить: Почему написано "!::IntrlockedDecrement( &m_nReferences )", а не

void CReferenceCounter::Release( void ) 
  {

  !::IntrlockedDecrement( &m_nReferences ) 
  if( !m_nReferences )
  {
     delete this;
  }
}

В чем отличие и проблемы?

S>В чем отличие и проблемы?

Главная проблема — в том, что не скомилируется (забыта ";", та, что должна дать sequence point и кучу проблем с этим).

Но строго говоря, Bulat прав — удалять объект сам себя из собственного же метода (даже если это Release) по-хорошему не должен. Можно придумать примеры, где это будет стрелять (но они, все ж, будут слегка экзотичны).

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

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

S>>Простой вопрос: поддержка целостности объекта через счетчик ссылок как в COM-t. Написать методы AddRef, Release.

A_N>Обычно приводят что-то такое:

A_N>

A_N>void CReferenceCounter::AddRef( void ) {
A_N>  ::IntrlockedIncrement( &m_nReferences );
A_N>}

A_N>void CReferenceCounter::Release( void ) {
A_N>  if( !::IntrlockedDecrement( &m_nReferences ) ) {
A_N>  delete this;
A_N>  }
A_N>}
A_N>

A_N>Либо синхронизируют через критическую секцию. А мне вот интересно, тут безопасно разве удалять объект? Если бы синхронизировали критической секцией, она бы была мембером класса, как удалить объект? Выйти из нее — а может в это время другой поток addRef сделает, а потом текущий, думая что счетчик 0, уничтожит. Не выходить из нее тоже нельзя.
A_N>Да и тут примерно такая ситуация вроде может быть — зашли в аddRef, в это время другой поток декрементировал и стер объект, и тут мы дошли в первом поток до вызова IntrlockedIncrement(). Может так быть?

Здесь все просто, всего лишь нужно задуматься "а кто может делать AddRef" ?

Ответ : тот кто имеет "валидный" интерфейс/хэндл, то есть пока этот хэндл валидный,
объект не будет удален даже вызовом Release() из другого потока.
Т.е. объект будет удален при вызове Release() у последнего "валидного" хэндла.

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

ПМ>Join-calculus, pi-calculus, CSP, STM, non-blocking IO без каллбеков и прочей содомии, nested data parallelism, модель акторов, temporal logic of actions и пр. Если начнут с умным видом прашивать про мьютексы/сигналы/эвенты — вставай и уходи.

Заинтриговали. Теперь, если нетрудно, разъясните, что вы тут написали. Я, кроме как про non-blocking IO, других терминов особо не встречал в обычной работе, за исключением разработки кодогенераторов (в т.ч. JIT, там действительно нужны некоторые добавочные знания, которые, я так понимаю, вы обозвали умными терминами nested data parallelism и temporal logic of actions — притом для конкретных железок).

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

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

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

S>>В чем отличие и проблемы?

SD>Главная проблема — в том, что не скомилируется

Ой!

SD>Но строго говоря, Bulat прав — удалять объект сам себя из собственного же метода (даже если это Release) по-хорошему не должен. Можно придумать примеры, где это будет стрелять (но они, все ж, будут слегка экзотичны).

Дело не в этом если Release вызван параллельно из 2х или более потоков, то первый поток сделает уменьшение "m_nReferences", а другие будут видеть 0 в m_nReferences и сделают double delete. В случае "if IntrlockedDecrement(&m_nReferences ) == 0 )" такая проблема не возникает, т.к. используется локальный результат вычисления, а не общий член m_nReferences

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

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

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

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

IID>>Я любил давать кандидатам задачку на реализацию семафора "вручную". При условии что остальные объекты синхронизации (ивенты, мьютексы и т.д.) у них есть. Казалось бы, но результат удивлял. Мало кто мог реализовать сразу и без ошибок. Многие не могли найти ошибку и/или исправить, когда на неё показывал пальцем.

A>У вас в проекте много "ручных" семафоров, если не секрет конечно ?

Ну вот, начинается. Рассуждения в ключе "если не используется то я знать не обязан". Ручных семафоров, разумеется, нет. Но если человек не может написать сам семафор, делает логические ошибки, ошибки синхронизации, или даже не знает что такое семафор — то в многопоточном программировании он лопух полный, и его за километр нельзя подпускать к таким проектам.

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

SD> Можно придумать примеры, где это будет стрелять (но они, все ж, будут слегка экзотичны).
Придумайте, стало интересно.

S>Дело не в этом если Release вызван параллельно из 2х или более потоков, то первый поток сделает уменьшение "m_nReferences", а другие будут видеть 0 в m_nReferences и сделают double delete. В случае "if IntrlockedDecrement(&m_nReferences ) == 0 )" такая проблема не возникает, т.к. используется локальный результат вычисления, а не общий член m_nReferences

оооот тут широкое поле для беседы. Например, можно потеоретизировать на тему volatile и ума современных компиляторов (кодогенераторов). В частности, один мне известный генератор (чисто для унутренного применения, вряд ли вы о нем слышали) для volatile-переменных сам генерирует префик lock для x86 (или соответствующую инструкцию для высших процессоров), эффективным образом повторяя interlocked-операции. Учитывая, что оптимизатор в общем случае свернет всю конструкцию, в ассемблере получим что-нибудь вида

lock sub ax, 1   ; или вариант для высших x86
jnz function_exit
call delete_this ; тут, конечно, будет не так, но это для иллюстрации
function_exit:

S>По поводу "удалять объект сам себя из собственного же метода" это спорно, т.к. техника refcount используется очень часто (как сопутствующий вопрос с интервью "где используется?") и если аккуратно написано, то очень хорошо работает

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

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

A_N>Предстоит важное собеседование, там сказали любят спрашивать различные вопросы про многопоточность под Win и давать разные задачки на эту тему.
A_N>А ктонить может подбросить задач и вопросов с собеседований про это все? Есть какие-либо "стандартные" задачи на это дело (ну как про круглые люки)?

http://rsdn.ru/forum/java/3622844.aspx

Автор: Golovach Ivan
Дата: 01.12.09

— с уклоном в Java, но есть и общие для всех ЯП вопросы

С такой логикой Вас тоже нельзя ни к чему допускать, кроме того , что вы знаете на данный момент.
Все когда-то в первый раз.
За месяц вполне можно все эти "трюки" с многопоточностью усвоить. Надо просто на первых порах следить за кодом новичка.

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

SD>lock sub ax, 1 ; или вариант для высших x86

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

HN>С такой логикой Вас тоже нельзя ни к чему допускать, кроме того , что вы знаете на данный момент.
HN>Все когда-то в первый раз.
HN>За месяц вполне можно все эти "трюки" с многопоточностью усвоить. Надо просто на первых порах следить за кодом новичка.

А с такой логикой надо брать вообще всех подряд Ведь всё можно усвоить и всему обучить. Нафиг-нафиг. В нашем случае необходимо было знание многопоточности сразу, без обучения. Это во-первых. А во-вторых, если кандидат декларирует знание многопоточности и валится на такой задачке — о чём вообще может идти речь ?

>А с такой логикой надо брать вообще всех подряд

Практика показывает, что некоторых обучить нельзя\очень сложно.

>В нашем случае необходимо было знание многопоточности сразу, без обучения. Это во-первых. А во-вторых, если кандидат декларирует знание многопоточности и валится на такой задачке — о чём вообще может идти речь ?

Согласен, если есть конкретные требования, тут уж ничего не поделаешь.
Просто обидно, когда чувствуешь, что "могешь" скорее всего, а опыта поднабраться негде.

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


>>А с такой логикой надо брать вообще всех подряд

HN>Практика показывает, что некоторых обучить нельзя\очень сложно.

Ага, именно так. Но ты всё равно предлагаешь этим заниматься.

>>В нашем случае необходимо было знание многопоточности сразу, без обучения. Это во-первых. А во-вторых, если кандидат декларирует знание многопоточности и валится на такой задачке — о чём вообще может идти речь ?

HN>Согласен, если есть конкретные требования, тут уж ничего не поделаешь.
HN>Просто обидно, когда чувствуешь, что "могешь" скорее всего, а опыта поднабраться негде.

Более того, "скорее всего" означает кучу говнокода, который на первый взгляд корректен, а на самом деле содержит кучу багов. А в многопоточном окружении ловить race condtition-ы то ещё "удовольствие". Опыта поднабраться всегда есть где =) Самостоятельные проекты, изучение текущего продукта, написанного более опытными товарищами, изучение стороннего открытого кода. Только для этого надо тратить время и силы, а особо ленивые уповают что их возьмут и так, а там авось как-нибудь научатся, да что-нибудь напишут, а другие пусть исправляют.

В ключе моего примера с семафором достаточно иметь базовые знания о примитивах синхронизации, да нормальную логику. Ну и аккуратность. Чтобы учесть все варианты поведения кода. Никаких супер-скиллов не нужно. Если кандидат не в состоянии решить такую задачу то и учить его бесполезно. Пусть базу подтягивает.

Много ты самостоятельных проектов ведешь?

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Здравствуйте, Aleksey_NN, Вы писали:

A_N>>Всем привет.

A_N>>Предстоит важное собеседование, там сказали любят спрашивать различные вопросы про многопоточность под Win и давать разные задачки на эту тему.
A_N>>А ктонить может подбросить задач и вопросов с собеседований про это все? Есть какие-либо "стандартные" задачи на это дело (ну как про круглые люки)?
A_N>>Для примера: на первом собеседовании меня пока попросили написать синхронизированную очередь.

ПМ>Join-calculus, pi-calculus, CSP, STM, non-blocking IO без каллбеков и прочей содомии, nested data parallelism, модель акторов, temporal logic of actions и пр. Если начнут с умным видом прашивать про мьютексы/сигналы/эвенты — вставай и уходи.

А что, кстати, плохого в вопросах про мьютексы/сигналы/ивенты. Разве эти примитивы не надо знать в первую очередь ?

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

A>А что, кстати, плохого в вопросах про мьютексы/сигналы/ивенты. Разве эти примитивы не надо знать в первую очередь ?

Обычно при разработке на плюсах используют boost, как давно boost знаком с виндовыми Event?

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

HN>Много ты самостоятельных проектов ведешь?

Не пойму какое это имеет отношение к обсуждению. Самостоятельных — в свободное время ? Сейчас один. Кернел-мод. Раньше несколько юзерлендных было, писал чисто для фана. Даже профит кое-какой приносили.

Имеет, т.к заниматься чем-то более менее серьезным в нерабочее время проблематично(время немного, да 24 часа за компом сидеть маразм). Книги почитать, что-то мелкое написать — да, еще можно.