Всем привет.

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

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

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

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

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

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

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

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

CriticalSection vs Mutex

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

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

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

1. Проблема обедающих философов.
2. Проблема читателей и писателей.
3. Проблема спящего брадобрея.

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

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

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

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

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

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

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

AK>1. Проблема обедающих философов.
AK>2. Проблема читателей и писателей.
AK>3. Проблема спящего брадобрея.

А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

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

U>А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

Это реализуется железом — контролером доступа к памяти, программист с этим не соприкасается.

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

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

U>>А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

S>Это реализуется железом — контролером доступа к памяти, программист с этим не соприкасается.

Ох еще как соприкасается, только, к сожалению, очень мало об этом знает.

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

U>Ох еще как соприкасается, только, к сожалению, очень мало об этом знает.

Например? А то может мы о разном говорим.

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

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

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

A_N>Либо синхронизируют через критическую секцию. А мне вот интересно, тут безопасно разве удалять объект? Если бы

мне тоже интересно, как можно додуматься удалять объект в его методе

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

A_N>>Либо синхронизируют через критическую секцию. А мне вот интересно, тут безопасно разве удалять объект? Если бы

BZ>мне тоже интересно, как можно додуматься удалять объект в его методе

А где еще удалять COM-объект?

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

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

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

U>>>А я бы попросил объяснить как CPUs между собой договариваются, кто и какие данные модифицирует, и как гарантируется то, что другие CPU не прочитают "грязные" данные. Вполне себе интересная тема.

S>>Это реализуется железом — контролером доступа к памяти, программист с этим не соприкасается.

U>Ох еще как соприкасается, только, к сожалению, очень мало об этом знает.

Поясните пожалуйста, если на потоке ставить мьютекс, то как с другого CPU читаются "грязные" данные ?

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

BZ>>мне тоже интересно, как можно додуматься удалять объект в его методе

L>А где еще удалять COM-объект?

в глобальной процедуре или в его владельце

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

L>>А где еще удалять COM-объект?

BZ>в глобальной процедуре или в его владельце

Я COM как бы не зря выделил.

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

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

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

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

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

A>Поясните пожалуйста, если на потоке ставить мьютекс, то как с другого CPU читаются "грязные" данные ?

Тут понимаете про потоки не сказано ни слова, только про процессоры. На разных процессорах могут исполняться разные потоки равно, как разные потоки могут исполняться на одном и том же процессоре. Акцент был сделать именно на процессорах, а аппаратные кеши процессоров синхронизируются аппаратно, можно только принудительно делать flush или отключать использование кэша с помощью флага CD у регистра cr0, можно с помощью флага NM у cr0 включая сквозную запись в память. Что автор имел ввиду непонятно, никакого контроля над тем, как CPU договариваются между собой нет.

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

S>Это реализуется железом — контролером доступа к памяти, программист с этим не соприкасается.

Реализуется-то железом. А тормозит-то потом софт.

Здравствуйте, 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 и пр. Если начнут с умным видом прашивать про мьютексы/сигналы/эвенты — вставай и уходи.

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

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

A>>Поясните пожалуйста, если на потоке ставить мьютекс, то как с другого CPU читаются "грязные" данные ?

S> Что автор имел ввиду непонятно, никакого контроля над тем, как CPU договариваются между собой нет.

вероятно, имелась ввиду ситуация, когда ЦП1 пишет в память, находящейся в кэше ЦП2. контроль на самом деле есть. не хочешь, чтобы возникала такая ситуация -- не вызывай ее.

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