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

U>Угу. Я бы был рад услышать про MESI, про store buffers, read/write memory barriers, prefetching etc. Много о чем поговорить можно. Но это так, мысли вслух

Главное — не увлекаться. А то опять появится релизация memcpy, которая падает при копировании во write-only memory

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

SD>Заинтриговали. Теперь, если нетрудно, разъясните, что вы тут написали.

Всё гуглится по названиям.

Аббревиатуры:
CSP — Communicating Sequential Processes
STM — Software Transactional Memory

Теперь всё точно гуглится.

SD>В любом случае, применение необщеупотребимых терминов сродни тяжелому codestyle.

Терминология стандартная.

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

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

Когда вы в последний раз реализовывали мьютекс/сигнал/эвент?

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

U>мыщъх, не могу не согласиться. Но как мало людей об этом знают... Хотя все горазды писать многопоточные приложения — кругом одни писатели.

Имхо кругом одни "читатели," if you know what I mean.

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

Абсолютно идиотская задача которая ничего не демонстрирует кроме как неадекватности ее спрашивающего.

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

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

Реализовать семафор в кернел моде намного проще и понятнее этого изврата который ты хочешь увидеть в юзер моде при помощи других примитивов.

ЗЫ. Ты такой умный! Тебе череп мозг не жмет? (с)

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

MP>Интересно, что ж вы там такое напедалить умудрились, что теперь без знания ручного семафора людей на проект брать опасно.

Сто процентов что что-нибудь да напедалили в этом стиле. Не семафор так что-то другое. Возможно даже все.

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

IID>Более того, "скорее всего" означает кучу говнокода, который на первый взгляд корректен,

Этот твой user-space semaphore и есть самый что ни на есть гавнистый говнокод, как бы аккуратно его не написали. А ты даже и не понимаешь этого.

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

Да ничего такого в этой многопоточности и синхронизации нет и зачастую она не нужна. Нужно просто понимать что такое потоки, как происходит их переключение, проблемы с ними связанные и примитивы синхронизации. Ну и иметь голову на плечах. А на интервью всего не спросить.

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

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

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

Это была иллюстрация. Не надо понимать буквально. Если мы хотим углубиться в изучение конкретных реализаций — можно продолжить обсуждение lock CMPXCHG (один из возможных методов, AFAIK, в Windows сделано так), вспомнить про cli/sti (ЕМНИП, в Linux c поддержкой многопроцессорности прерывания локального процессора запрещаются при работе в режиме ядра), потрещать о еще одной реализации Solaris/Linux (где вообще нет decrement — есть только add, к счастью, signed, — в итоге тот же boost пользует очень даже платформо-зависимый __sync_fetch_and_add).
Но прямого отношения к теме всё это не имеет — а подавляющее большинство программистов вообще никогда не полезет в конкретную реализацию atomic_* функций. Даже если это ядерный программист. Поэтому начальной иллюстрации более чем достаточно.
Вот если бы начали барьеры обсуждать (к этому уже пришли, я смотрю, ближе к концу ветки), еще было бы понятен ваш сарказм.

M>Придумайте, стало интересно.

Есть набор очевидных проблем (перечислены здесь: http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15). Самое важное — надо внимательно следить, чтобы объект ненароком не был на стеке или еще где-то в странном месте. Например, размещен placement new — очень частый случай для мелких COM-объектов, в больших количествах создаваемых какой-нибудь homebrew IClassFactory — какие-нибудь "обёрточные" объекты, которые быстрее из пула доставать, чем постоянно создавать/уничтожать.

Кстати, подумалось, что есть хороший вопрос на внимательность для собеседования:

class RefCountable
{
  Mutex m;
  int ref_counter;
  void Release()
  {
    m.lock();
    --ref_counter;
    if (ref_counter == 0) delete this;
    m.unlock();
  }

Требуется исправить код (сразу предупрежу, я не компилировал и не проверял синтаксическую правильность — это код для иллюстрации).

ПМ>Теперь всё точно гуглится.

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

Здравствуйте, SkyDance, Вы писали:
SD>Самое важное — надо внимательно следить, чтобы объект ненароком не был на стеке или еще где-то в странном месте.
Создавать СОМ обьекты на стеке Вообщето их принято фабрикой создавать, и согласовать размещение обьекта с фабрикой не является проблемой.

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

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

КД>>Прикладному программисту это по-барабану.

U>Почитайте ответы уважаемого Мыщъх, он привел кучу примеров, почему прикладному программисту как раз не по барабану. Есть все шансы, что Ваша многопоточная программу будет лучше работать на single CPU будет работать лучше и быстрее.

Я уже давно положил на примеры, меня интересуют законченные решения. Как они там внутри сделаны, меня начинает интересовать только если они начинают выносить мне моск

Впрочем да, встречал программистов, которые создавая код на VBScript рассуждают об ассемблере. Или, что ближе к теме топика, не в состоянии раскрутить причину AV в коде (сервера RDBMS) вида

assert(ptr!=NULL);
(*ptr)=0; //AV, потому что ptr таки оказался равным NULL

при этом размышляя — неужто это бага в процессоре AMD?

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

U>В общем, Вы не прошли собеседование многопоточному программированию.
В таких вещах самым лучшим будет демонстрация собственных произведений по теме. У меня такое есть. И самое краткое, что я мог бы сказать про него, что расстояние от CreateThread до промышленного решения (которое не страшно выпускать в дикую природу), управляющего потоками, в моем случае составило сотню килобайт исходного кода на C++. Прикладной код, где эти потоки потом работают — на порядок больше и сложнее. А то, где оно все целиком эксплуатируется — это вообще тихий ужос

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

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

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

Для этого нужно иметь реально мега крутое сознание

Помнится, в 97 году я чуть не рехнулся когда пытался до него самостоятельно додуматься. Ниасилил.

Чуть позже прочитал про него в книжке "Основы COM". К сожалению, моск к этому моменту уже был необратимо поврежден

На текущий момент, лично по мне, "delete this" — это одно из немногих обоснованных, явных использований оператора delete. В методе декремента счетчика ссылок на объект

---
Да, кстати, а объекты со счетчиками ссылок — это единственные кандидаты на роль совместно используемых ресурсов в многопоточной программе. Опять же — моё скромное мнение. Правда, нужно знать базовые правила управления такими объектами

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


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

Проблема не в знаниях, а в доступном времени. Разработчик для создаваемой фичи может осуществить только конечный набор мероприятий. Он должен подумать и тысячи разных вещах: проверок результатов API, синхронизация, unit test-ы, документация и еще много чего. Поэтому знания и действия должны быть четко приоритизированны. Если прикладной программист начнет еще размышлять над тем как там железо осуществляет доступ к ячейкам памяти или какой алгоритм заложен в ЦПУ, то он не успеет сделать что-то более важное, к примеру, написать хороший комментарий в код. Не надо требовать от разработчика не профильными знаниями, он о них может почитать в журналах для самообразования.

Я не думаю, что это кого-то интересует.

N_>Создавать СОМ обьекты на стеке Вообщето их принято фабрикой создавать, и согласовать размещение обьекта с фабрикой не является проблемой.

При чем тут стек?
Я же написал там про реализацию IClassFactory с применением пула готовых объектов (чтобы сэкономить на выделении памяти и инициализации).

Стек — это уже было в рамках обсуждения delete this; а не про конкретно СОМ-объекты.

Здравствуйте, мыщъх, Вы писали:

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

Интересно, а как преобразовать задачу Producer-consumer, чтобы избежать ситуации "один поток заталкивает элементы в объект, а другой их оттуда выпихивает"? (Естественно, помимо отказа от многопоточности вообще)

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

M>>Придумайте, стало интересно.

SD>Есть набор очевидных проблем (перечислены здесь: http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15). Самое важное — надо внимательно следить, чтобы объект ненароком не был на стеке или еще где-то в странном месте. Например, размещен placement new — очень частый случай для мелких COM-объектов, в больших количествах создаваемых какой-нибудь homebrew IClassFactory — какие-нибудь "обёрточные" объекты, которые быстрее из пула доставать, чем постоянно создавать/уничтожать.

Спасибо, это конечно не интересно. Я думал что то другое.

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

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

Честно сказать, не понял чем эта задача хуже "8 гномиков встали раком" либо переверните однонаправленный список или любая другая задача ни о чем. Даже удивительно что народ столько возмущается, неужели написание такой простой херотени доставляет какие-то трудности?