Долгое время даже и не знал что написать в ответ, хотя мысли разные приходили.
В основном ваши вопросы затрагивают около-фундаментальные темы вперемешку с Java API,
который можно открыть и почитать или посмотреть исходные коды.
Или, к примеру, Java программист не обязан знать Erlang — не понятно откуда появился этот вопрос.
т.е. как бы около-фундаментальные знания выуживаются из реализаций, а не из факта изучения фундаментальных книг.
The Art of Multiprocessor Programming — у меня, кстати, есть эта книга и я её читал, но она не очень интересна —
посмотреть, конечно, можно. На самом деле, судя по вашим вопросам, вы еще очень многих интересных фундаментальных книг не читали.
т.е. не все вопросы мне кажутся бесмысленными, но сократить логически список нужно.
Здравствуйте, insighter, Вы писали:
I>а какого рода у вас в фирме задачи по многопоточности, что такой серьезный список вопросов?
Последний проект что был — высоконагруженный распределенный игровой сервер. Собственно основные "многопоточные абстрактности" появились когда начали делать его модульным. Конкретно:
— игра — это просто jar-ник брошенный в папку (а всего на одном сервере параллельно висит от 40 до 160 типов игр, и у каждого несколько инстансов для каждого игрока);
— "акции"(как в казино — система лотерей) — это просто листенеры на события происходящие в играх(старт, ставка, выигрыш, отмена, проигрыш, и т.д.), получающие ивенты по самописной in-process очереди сообщений.
Предпоследний проект — сомописный транзакционный менеджер. Понадобился, когда увязывали работу с несколькими сайтами через один "суперсайт". Особенность была в том, что в каждый момент времени было огромное количество незавершенных транзакций (как на commit-е так и на rollback-е), иногда транзакцию не удавалось завершить буквально сутками (сайт просто отказывается работать именно с этим аккаунтом) и с тем что не для всех действий возможно было написать rollback-действие (скажем, если на счет сайта перечислили деньги, то отменить перевод нельзя никаким образом, возможно только взять другой услуги на эту же сумму) — из-за этого и других "особенностей" писали сами.
Собственно, многопоточность(в том числе терминология, алгоритмы — не только Java API) — это инструментарий, владея им проекты получаются "красивее", быстрее, лаконичнее и, зачастую, функциональнее. Это как Spring, для разработки серверного приложения на Java, в принципе, никакой контейнер не является НЕОБХОДИМЫМ(ни IoC, ни EJB, ни ???), все можно сделать вручную, изобрести кучу велосипедов. Но заметно проще опираться на разработки других. Так и тут, владея инструментарием автоматически начинаешь им пользоваться.
Собственно, пришел к тому, что работа становится следствием умений, а не наоборот. Т.е. ни "Какая работа заставила выучить многопоточность?", а "За какую работу Вы взялись зная многопоточность(алгоритмы, криптографию, etc)?".
Перед этим работал в паре небольших стартапов, сейчас в свободном плавании, рассматриваю предложения
Здравствуйте, markovskiy, Вы писали:
M>Здравствуйте, Golovach Ivan, Вы писали:
M>Долгое время даже и не знал что написать в ответ, хотя мысли разные приходили. M>В основном ваши вопросы затрагивают около-фундаментальные темы вперемешку с Java API,
Согласен. Но это же собеседование на работу, а не на PhD в Стенфорд.
M>который можно открыть и почитать или посмотреть исходные коды.
Опять же — ищется сотрудник, который уже способен с этим работать, а не в состоянии разобраться. Опять же, если человеку необходимо смотреть множество API — это скорее всего к тому, что будет наличие трудноотловимых ошибок. Что-то вроде — "читаю со словарем".
M>Или, к примеру, Java программист не обязан знать Erlang — не понятно откуда появился этот вопрос.
Собственно не совсем понятно что вообще "должен знать Java программист". Только вот Twitter использует Scala, а Facebook — Erlang. Да и близкое знакомство с концепцией actor-ов не помешает.
M>т.е. как бы около-фундаментальные знания выуживаются из реализаций, а не из факта изучения фундаментальных книг.
Согласен. Я же для этого и говорю про первый-второй-третий уровень знаний. Тут вопросы по первому, немного по второму. Вы же хотели бы видеть третий. Но это — не ко мне, не дорос пока еще
M>The Art of Multiprocessor Programming — у меня, кстати, есть эта книга и я её читал, но она не очень интересна - M>посмотреть, конечно, можно. На самом деле, судя по вашим вопросам, вы еще очень многих интересных фундаментальных книг не читали.
Вы могли бы указать конкретный список книг?
M>т.е. не все вопросы мне кажутся бесмысленными, но сократить логически список нужно.
На собеседовании на работу зачастую большинство вопросов кажется "бессмысленными", есть такая беда.
С удовольствием прочитаю Ваш список дополнительных вопросов.
... > Последний проект что был — высоконагруженный распределенный игровой > сервер. Собственно основные "многопоточные абстрактности" появились > когда начали делать его модульным. Конкретно: > — игра — это просто jar-ник брошенный в папку (а всего на одном сервере > параллельно висит от 40 до 160 типов игр, и у каждого несколько > инстансов для каждого игрока); > — "акции"(как в казино — система лотерей) — это просто листенеры на > события происходящие в играх(старт, ставка, выигрыш, отмена, проигрыш, и > т.д.), получающие ивенты по самописной in-process очереди сообщений. > > Предпоследний проект — сомописный транзакционный менеджер. Понадобился, > когда увязывали работу с несколькими сайтами через один "суперсайт". > Особенность была в том, что в каждый момент времени было огромное > количество незавершенных транзакций (как на commit-е так и на > rollback-е), иногда транзакцию не удавалось завершить буквально сутками > (сайт просто отказывается работать именно с этим аккаунтом) и с тем что > не для всех действий возможно было написать rollback-действие (скажем, > если на счет сайта перечислили деньги, то отменить перевод нельзя > никаким образом, возможно только взять другой услуги на эту же сумму) — > из-за этого и других "особенностей" писали сами. > > Собственно, многопоточность(в том числе терминология, алгоритмы — не > только Java API) — это инструментарий, владея им проекты получаются > "красивее", быстрее, лаконичнее и, зачастую, функциональнее. Это как > Spring, для разработки серверного приложения на Java, в принципе, > никакой контейнер не является НЕОБХОДИМЫМ(ни IoC, ни EJB, ни ???), все > можно сделать вручную, изобрести кучу велосипедов. Но заметно проще > опираться на разработки других. Так и тут, владея инструментарием > автоматически начинаешь им пользоваться. > > Собственно, пришел к тому, что работа становится следствием умений, а не > наоборот. Т.е. ни "Какая работа заставила выучить многопоточность?", а > "За какую работу Вы взялись зная многопоточность(алгоритмы, > криптографию, etc)?". > > Перед этим работал в паре небольших стартапов, сейчас в свободном > плавании, рассматриваю предложения
Судя по представленным проектам компания действительно делала довольно
сложные вещи. Значит у нее есть разработчики высокой квалификации. И тем
не менее, она ищит супер-пупер разработчика. Страннно.
Во-первых это дорого. Я, к примеру, не смог бы пройти такое
собеседование, но меньше 2 тыщь баксов и не стал бы рассматривать. А
тот, кто сможет, думаю и пятью тысячами останется недовольным.
Во-вторых — как компания собирается интегрировать такого разработчика в
комманду? Такие разработчики не смогут воплощать чью-то архитектуру. Они
конечно смогут, если требуемая архитектура совпадает с их видением — но
тогда зачем они вам? А если поставить нового разработчика в комманду
выше своих старых сотрудников — это посеет неприязнь между руководством
компании, старыми сотрудниками и новым разработчиком. Как минимум будет
нарушение коммуникации.
"работа становится следствием умений, а не наоборот" — О ЧЕМ ЭТО
ВООБЩЕ??? Пойдите в любой институт, найдите какого-нибудь аспиранта с
кафедры философии, и попросите объяснить вам, что является следствием, а
что причиной (в этой паре работа-умение).
Вернемся к компании, которая ищет супер-пупер разработчика по
Concurrency. Что же могло заставить компанию, которая справляется с
решением сложных проектов искать супер-разработчика? Его дорого искать,
его дорого содержать, его трудно интегрировать в комманду. Мне кажется,
что проблема в "текучке".
Думаю у компании был разработчик (а может быть несколько). Компания
сделала один или несколько продуктов которые хорошо "выстрелили"
(принесли большую прибль). Но компания не поделилась этой приблью с
разработчиком.
А что, мы и не обещали! Это же мы (компания) рисковали своими деньгами,
несколько лет платили зарплату, медстраховку, отпуски, офис... Мы же
регулярно индексировали зарплату. Ну и что, что теперь мы каждый месяц
зарабатываем по миллиону баксов в месяц. Нет, мы не можем заплатить
разработчикам по миллиону — нам же для этого придется несколько месяцев
оставаться без прибыли. Мы даже по 100 тыщь не можем заплатить — это же
огомные деньги. Да и на каком основании — мы так не договаривались!
В итоге — мотивация ушла, разработчики или ушли, или не могут работать
(из-за отсутствия мотивации). Важная часть успеха — опыт разработчиков —
утрачен...
А компания ищет техническое решение социальной проблемы. Придется
огорчить такую компанию — социальные проблемы решаются социальными методами.
Остается только опуститься на примитивный уровень, и сказать, что старые
разработчики ушли из-за своей жадности.
Здравствуйте, Other Sam, Вы писали:
OS>Судя по представленным проектам компания действительно делала довольно OS>сложные вещи. Значит у нее есть разработчики высокой квалификации. И тем OS>не менее, она ищит супер-пупер разработчика. Страннно.
Это чисто субъективно — но это требования не к супер-пупер разработчику.
Достаточно прочитать около "правильных" 10 книг.
OS>Во-первых это дорого. Я, к примеру, не смог бы пройти такое OS>собеседование, но меньше 2 тыщь баксов и не стал бы рассматривать.
Да, Java senior меньше 2000$, полагаю, нигде не получает.
OS>тот, кто сможет, думаю и пятью тысячами останется недовольным.
Ну я, например, остаюсь доволен суммой меньшей чем 5 тонн. В принципе если
знание многопоточки добавляет +500 к зп — уже неплохо.
+100 за XML, +300 за криптографию, +300 за Oracle — так на сеньерскую зп и набегает
OS>Во-вторых — как компания собирается интегрировать такого разработчика в OS>комманду? Такие разработчики не смогут воплощать чью-то архитектуру. Они OS>конечно смогут, если требуемая архитектура совпадает с их видением — но OS>тогда зачем они вам? А если поставить нового разработчика в комманду OS>выше своих старых сотрудников — это посеет неприязнь между руководством OS>компании, старыми сотрудниками и новым разработчиком. Как минимум будет OS>нарушение коммуникации.
Возможно Ваши выводы справедливы для большой оутсорсной компании, но
в стартапах немного другая атмосфера. Нет такого процесса как "интеграция разработчика".
На собеседовании прямо говорят — вот что мы делаем, такие задачи решаем.
Если интересно — давая работать к нам. И боец идет на решения интересных задач.
Атмосфера обсуждения чье решение лучше присутствует постоянно, если докажешь, что
твое лучше — внедряют его.
OS>"работа становится следствием умений, а не наоборот" — О ЧЕМ ЭТО OS>ВООБЩЕ??? Пойдите в любой институт, найдите какого-нибудь аспиранта с OS>кафедры философии, и попросите объяснить вам, что является следствием, а OS>что причиной (в этой паре работа-умение).
Это верно для навыков, получаемых в результате работы. Тут согласен.
Но Вы же и сами можете за сезон прочитать пяток книг по криптографии
и теперь выбирать работу с ее использованием. Идти по некоторому своему
плану развития.
OS>Вернемся к компании, которая ищет супер-пупер разработчика по OS>Concurrency. Что же могло заставить компанию, которая справляется с OS>решением сложных проектов искать супер-разработчика? Его дорого искать, OS>его дорого содержать, его трудно интегрировать в комманду. Мне кажется, OS>что проблема в "текучке".
... OS>Остается только опуститься на примитивный уровень, и сказать, что старые OS>разработчики ушли из-за своей жадности.
Не единственный вариант. Я обычно сталкивался с тем, что создается команда, скажем
2 сениора, 3 мида, 3 юниора. Работает, все ок, но потом в результате увеличения
количества работы сеньеры начинают захлебываться и требуют от командования
еще, скажем 1 сениора, и пару мидлов. Ну вот этого сениора и подбирают долго и нудно.
Т.е. Вы не рассматриваете вариант роста команды, а только замещения ее членов.
Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
Здравствуйте, mselez, Вы писали:
M>высоконагруженный распределенный
M>Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
кстати, не исключено
мне доводилось поставлять решения клиенту, который потихоньку по мере роста выбрал лимит железа в дата-центре, который был ему удобен экономически и географически. начиная с какого-то момента, стало ясно, что это ещё не пик нагрузки, но разом переместить все данные куда-то ещё было практически невозможно, клиент в силу своих экономических внутренних аргументов решил пойти по пути оптимизации софта...
Здравствуйте, mselez, Вы писали:
M>высоконагруженный распределенный
M>Означает ли это, что все имеющееся в наличии у компании "железо" работает с перегрузкой, а добавить еще "железа" почему-то нет возможности ( ), и вот приходится погружаться на "молекулярный" уровень.
1)
Железо было неплохое, но мы уперлись в архитектурные ограничения. Одно из требований было держать 400tps. Но проблема в том, что запросы от пользователей не независимы. Есть много мест, где без вдумчивого подхода происходит сериализация запросов и никакими 400tps не пахнет — падает до 5-15tps. Конкретный пример — модуль "Акции" содержал акцию "Джек-пот", если кратко, то это отчисления с каждой ставки некоторого процента в джек-пот. Тот пользователь, чье отчисление превысило некоторую(секретную) сумму джек-пота — забирает его("сорвать джек-пот"). Сумма существенная, скажем 50.000$. Хитрость в том, что, допустим, каждый игрок отчисляет по 1$, но мы не можем так просто 50.000-ному запросу дать сорвать джек-пот, так как если откатятся предыдущие транзакции, то наш игрок уже не 50.000ный, а, скажем, 49.990-ый. Т.е. в момент потенциального срыва джек-пота приходится либо сериализировать запросы, либо приостанавливать потенциального победителя и вешать его на ожидание коммитов предидущих запросов, но пока 50.000ный не сорвал джек-пот, не понятно что делать с 50.001, 50.002, 50.003 ... — запросами. Ведь любой из них может сорвать джек-пот в случае роллбека скажем 49.999 запроса (а по условиям мы должны были сообщать об этом в запросе-победителе). Т.е. происходит сразу же нарастание очереди ожидания запросов.
А теперь представьте, что сервер будет сдан "сейчас", а модули акций будут дописываться "потом", в течении всей жизни проекта (ну такие вот условия у этого бизнеса). И многие акции должны иметь возможность использовать "глобальные интегральные" характеристики, типа — кол-во запросов до моего, сумма ставок до моей, абсолютный номер моего запроса. И вот при разработке API игрового сервера для подключаемых акций и вылазили все эти "оптимистические блокировки", "условные ожидания", "copy-on-write" но скорее не в смысле java.util.concurrent.*, а в смысле архитектурных решений.
2)
Продукт писался коробочный, так что тут чем ниже требования к железу, тем желательнее для компании.
Здравствуйте, Golovach Ivan, Вы писали:
GI>Железо было неплохое, но мы уперлись в архитектурные ограничения. Одно из требований было держать 400tps. Но проблема в том, что запросы от пользователей не независимы. Есть много мест, где без вдумчивого подхода происходит сериализация запросов и никакими 400tps не пахнет — падает до 5-15tps. Конкретный пример — модуль "Акции" содержал акцию "Джек-пот", если кратко, то это отчисления с каждой ставки некоторого процента в джек-пот. Тот пользователь, чье отчисление превысило некоторую(секретную) сумму джек-пота — забирает его("сорвать джек-пот"). Сумма существенная, скажем 50.000$. Хитрость в том, что, допустим, каждый игрок отчисляет по 1$, но мы не можем так просто 50.000-ному запросу дать сорвать джек-пот, так как если откатятся предыдущие транзакции, то наш игрок уже не 50.000ный, а, скажем, 49.990-ый. Т.е. в момент потенциального срыва джек-пота приходится либо сериализировать запросы, либо приостанавливать потенциального победителя и вешать его на ожидание коммитов предидущих запросов, но пока 50.000ный не сорвал джек-пот, не понятно что делать с 50.001, 50.002, 50.003 ... — запросами. Ведь любой из них может сорвать джек-пот в случае роллбека скажем 49.999 запроса (а по условиям мы должны были сообщать об этом в запросе-победителе). Т.е. происходит сразу же нарастание очереди ожидания запросов.
Раз уж пошла такая пьянка, а чем вызвана возможность ролбека? Вроде как запрос уже весь пришёл, после его валидации (которая обычно может проводиться полностью независимо), что может вызвать роллбек?
И ещё интересно почему в сериализованном режиме обрабатывалось всего 10 транзакций в секунду? Судя по описанию тут вроде никаких особо тяжёлых рассчётов нет. Ввод-вывод, парсинг запроса, формировнаие ответа — вполне может идти параллельно; а сама обработка вроде не особо тяжёлая...
Здравствуйте, Golovach Ivan, Вы писали:
GI>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>Достаточно прочитать около "правильных" 10 книг.
Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
Здравствуйте, chand0s, Вы писали:
C>Здравствуйте, Golovach Ivan, Вы писали:
GI>>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>>Достаточно прочитать около "правильных" 10 книг.
C>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
Заходите на Amazon.com, выбираете в Search раздел Books, печатаете в строке запроса "Parallel Programming".
На билжайший год книг хватит.
Здравствуйте, chand0s, Вы писали:
C>Здравствуйте, Golovach Ivan, Вы писали:
GI>>Это чисто субъективно — но это требования не к супер-пупер разработчику. GI>>Достаточно прочитать около "правильных" 10 книг.
C>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список.
] я уже писал
"- Java Concurrency in Practice
— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition
— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit)
— по алгоритмам: The little book of semaphores = http://www.greenteapress.com/semaphores/
— по структурам данных: "Concurrent Data Structures" = http://www.cs.tau.ac.il/~shanir/concurrent-data-structures.pdf
— по JMM возьмите отсюда — http://kharkovconcurrencygroup.blogspot.com/2009/09/jmm.html
— advanced JMM = очень полное и детальное описание модели памяти Java (Java Memory Model, JMM) с описанием целей, которые ставились при разработке, и компромиссных решений, которые приходилось принимать = http://unladen-swallow.googlecode.com/files/journal.pdf (thanks to Remark)
— это тусовка вообще всех товарищей из Java concurrency community = http://cs.oswego.edu/pipermail/concurrency-
interest/"
В принципе первых трех уже вполне достаточно. Если Вы стартуете "с нуля" в многопоточности явы перед этими книгами возможно стоит просмотреть Java Thread Programming(Sams) или Java Threads(OReilly)
перечисленные книжки все в основном по прогопоточности в java, а вот какие-нибудь фундаментальные имеются?
Изобретут вон в дотнете какие-нибудь новые concurrency паттерны — опять переучивать?
Или все так и будет сводится к тем же семафорам и CAS-ам на аппартном уровне и соотв-но паттерны описанные в java мало чем будут отличаться от реализаций в других языках?
C>>Вы про какие-то абстрактные книги говорите или имеете в виду вполне конкретные книги? Если конкретные — приведите пожалуйста список. GI>тут[http://rsdn.ru/forum/java/3633148.1.aspx
] я уже писал GI>"- Java Concurrency in Practice GI>— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition GI>— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit) GI>— ...
Здравствуйте, swein2, Вы писали:
S>Топик конечно старый, S>но раз уж я на него набрел вчера то не поленился и написал ответы у себя http://swein2.blogspot.com/2011/10/concurrency.html
16 — неправильно. isAlive тоже создает happens-before
Здравствуйте, Безон, Вы писали:
Б>Здравствуйте, swein2, Вы писали:
S>>Топик конечно старый, S>>но раз уж я на него набрел вчера то не поленился и написал ответы у себя http://swein2.blogspot.com/2011/10/concurrency.html Б>16 — неправильно. isAlive тоже создает happens-before
. Особенность была в том, что в каждый момент времени было огромное количество незавершенных транзакций (как на commit-е так и на rollback-е), иногда транзакцию не удавалось завершить буквально сутками (сайт просто отказывается работать именно с этим аккаунтом) и с тем что не для всех действий возможно было написать rollback-действие (скажем, если на счет сайта перечислили деньги, то отменить перевод нельзя никаким образом, возможно только взять другой услуги на эту же сумму) — из-за этого и других "особенностей" писали сами.
), и вот приходится погружаться на "молекулярный" уровень.
