Здравствуйте, VovkaMorkovka, Вы писали:
VM>Здравствуйте, mik1, Вы писали:
M>>Любой сильный разработчик ответит процентов на 80 этих вопросов. Даже если человек ответит на половину из этого, он, имхо, уже весьма не слаб... M>>Ответов, кстати, не прошу. Просто привел пример того, что мог бы спросить (в реальности спрашивать придется, есс-но только какое-то подмножество).
VM>Ну вот, я знаю ответ на половину вопросов и это при том, что я НЕ системный програмист — игры делаю причем флешовые.... Как Вы понимаете, в играх знаю поболее. На какую — же сумму мне претендовать судя по ВАШЕЙ — же классификации?
Мои вопросы в основном подразумевают ширину ответа. Можно 10 словами ответить, можно 10 минутами. Разница существенная. В каком объеме вы ответите, я не знаю.
Я, кстати, тоже не драйверами деньги зарабатываю. Всё вокруг баз данных танцы с бубнами пляшу.
Ну и то, что сказали до меня — сама многопоточность — это только одна из сторон программиста. Главное, все-таки, это предметная область. Например, разработка серверного бэкэнда на плюсах с доступом к Ораклу. В первую очередь нужны плюсы и pl/sql, а во вторую — многопоточность. Да и то, если какой-то фреймворк для сервера уже есть, то от многопоточности обычно рожки до ножки остаются — пишешь какие-то аналоги процедур потоков, а инфраструктуру уже имеешь.
Здравствуйте, mik1, Вы писали:
M>>>Хотя редкий птиц наберется глубоких знаний в тех областях за 2 года. Да и многопоточность там упоминается, а если я начну по ней мучать соискателей, там 95% отсеять можно. LM>>Интересно попробывать. Меня по аське отсобеседуешь? M>Да я могу и тут написать, что бы я спрашивал в первую очередь. M>Для начала немного бы пробежался по теории, а потом бы перешел к практике реализации на том языке (плюсы или ява), на который собеседуется человек. M>1. Что такое поток, процесс? Чем они отличаются?
В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п.
M>2. Какие другие виды абстракций, описывающих отдельно выполняющийся поток команд со своим стеком данных вы знаете (в любых операционках).
Пул.
M>3. Обмен данными (или сообщениями) между потоками и процессами. Как переслать данные между потоками, процессами? Это вопрос на ширину кругозора и на понимание.
Pipes, shared memory, WM_COPYDATA(вспомнил не сразу), сокеты(это для извращенцев, т.е. для меня ) M>4. Синхронизация потоков. Зачем она нужна.
Лень писать. Веришь, что знаю? M> Тут же можно написать две функции потоков, изменяющие по паре переменных более чем на единицу (чтобы не скомпилировалось в ассемблерные inc или dec). Спрошу, чему равны значения переменных на выходе из потока. Потом можно вспомнить, что процессор может переставлять местами команды и усложнить задачку в эту сторону.
Не понял о чем вопрос. О блокировках или атомарных функциях
M>5. Atomic-функции. Что это такое, как их использовать.
Знаю, что такое название не вспомню. Нужны для "быстрого"(по сравнению с различными локерами) и threadsafety изменения данных M>6. Какие вам известны примитивы синхронизации. Какие из примитивов в Виндоузе уходят в режим ядра, какие остаются в пользовательском режиме (только для плюсов под форточки). Какие примитивы можно делить между процессами (тут же можно спросить пример из жизни, как это использовали).
Крит. секция(вначале может болтатся в пользовательском режиме), ивенты, семафоры, мьютексы
M>7. Можно поспрашивать, что конкретно делает определенный примитив синхронизации. Мьютекс, семафор, критическая секция...
Можно ответить на все
M>Дальше по языку пошел бы. M>По плюсам в виндоузе M>-какими функциями создаются примитивы
Не помню, давно WinApi не юзал M>-какой функцией освобождаются все примитивы ядра
CloseHandle? M>-какую функцию корректно использовать для создания потока
beginthread, beginthreadex, don't use CreateThread and etc M>По плюсам вообще поспрашивал бы о знании кроссплатформенных библиотек, реализующих многопоточность. Но это мое слабое место — нет практического опыта.
boost::thread , pthread
M>По яве
<skipped>
Не хочу в угадайку играть
M>Любой сильный разработчик ответит процентов на 80 этих вопросов. Даже если человек ответит на половину из этого, он, имхо, уже весьма не слаб... M>Ответов, кстати, не прошу. Просто привел пример того, что мог бы спросить (в реальности спрашивать придется, есс-но только какое-то подмножество).
Ответы привел Подхожу?
Здравствуйте, LuciferMoscow, Вы писали:
M>>1. Что такое поток, процесс? Чем они отличаются? LM>В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п.
Не услышал ответа на вопрос что такое поток и процесс. Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой.
M>>2. Какие другие виды абстракций, описывающих отдельно выполняющийся поток команд со своим стеком данных вы знаете (в любых операционках). LM>Пул.
Пулы чего? Мне на этот вопрос первыми приходят виндовые фиберы. Для продвинутых можно вспомнить green (light-weight) потоки, реализуемые в различных функциональных языках, типа Erlang.
M>>3. Обмен данными (или сообщениями) между потоками и процессами. Как переслать данные между потоками, процессами? Это вопрос на ширину кругозора и на понимание. LM>Pipes, shared memory, WM_COPYDATA(вспомнил не сразу), сокеты(это для извращенцев, т.е. для меня )
Ну да. Для извращенцев еще memory-mapped files.
M>>4. Синхронизация потоков. Зачем она нужна. LM>Лень писать. Веришь, что знаю?
Тут поверю.
M>> Тут же можно написать две функции потоков, изменяющие по паре переменных более чем на единицу (чтобы не скомпилировалось в ассемблерные inc или dec). Спрошу, чему равны значения переменных на выходе из потока. Потом можно вспомнить, что процессор может переставлять местами команды и усложнить задачку в эту сторону. LM>Не понял о чем вопрос. О блокировках или атомарных функциях
Нее.
int a = 0;
int b = 0;
void funcA()
{
a = a + 4;
b = b - 3;
}
void funcB()
{
a = a - 4;
b = b + 3;
}
Теперь запускаем два потока с указанными функциями потоков. Чему равны переменные на выходе из потоков? Это простейший тест на понимание многопоточности. Здесь ответ — да черт его знает. Причем даже наиболее вероятного ответа нет.
Ну и чуть позлее тест.
int a = 0;
int b = 0;
void funcA()
{
a = a + 4;
if (b == 3) b = b - 3;
}
void funcB()
{
b = b + 3;
if (a == 4) a = a - 4;
}
Опять же — чему равны значения переменных на выходе из потоков. Здесь можно даже уточнить, что потоки стартуют на многопроцессорной машине гарантированно одновременно (при помощи барьера какого-нибудь это организуемо). Здесь уже вопрос на понимание человеком латентности памяти и out-of-order execution. Здесь ответ — в большей части тестов будет a = 4, b = 3.
M>>5. Atomic-функции. Что это такое, как их использовать. LM>Знаю, что такое название не вспомню. Нужны для "быстрого"(по сравнению с различными локерами) и threadsafety изменения данных
Нужны они, по делу, только для реализации lock-free алгоритмов. Тут, кстати, сразу нужно задать вопрос, а гарантированно ли они выполняют свою задачу.
M>>6. Какие вам известны примитивы синхронизации. Какие из примитивов в Виндоузе уходят в режим ядра, какие остаются в пользовательском режиме (только для плюсов под форточки). Какие примитивы можно делить между процессами (тут же можно спросить пример из жизни, как это использовали). LM>Крит. секция(вначале может болтатся в пользовательском режиме), ивенты, семафоры, мьютексы
Ага.
M>>Дальше по языку пошел бы. M>>По плюсам в виндоузе M>>-какими функциями создаются примитивы LM>Не помню, давно WinApi не юзал M>>-какой функцией освобождаются все примитивы ядра LM>CloseHandle? M>>-какую функцию корректно использовать для создания потока LM>beginthread, beginthreadex, don't use CreateThread and etc M>>По плюсам вообще поспрашивал бы о знании кроссплатформенных библиотек, реализующих многопоточность. Но это мое слабое место — нет практического опыта. LM>boost::thread , pthread
LM>Ответы привел Подхожу?
Черт его знает. По ответам тут — определенное понимание есть
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Я говорил о провинциальном городе — миллионнике, в областном центре с населением 500 чел. и меньше да, весьма мрачно...
Хабаровск — это не просто областной центр, это самый крупный город на Дальнем востоке. И народа больше 500 000. Наболело...
VM>Имеет мне смысл ехать на сумму меньше 3000$?
Есть коллеги с моего отдела, которые переехали. По их словам цены на еду, одежду, оргтехнику действительно ниже чему у нас в Хабаровске. Проживая полгода в Москве отложили больше чем у нас за 2 года. Это, так сказать, эмпирический результат. Поэтому ехать есть смысл даже за ту же зарплату.
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, LuciferMoscow, Вы писали:
M>>>1. Что такое поток, процесс? Чем они отличаются? LM>>В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п.
M>Не услышал ответа на вопрос что такое поток и процесс. Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой.
Чисто для поддержания дискуссии:
В POSIX описаны процессы и потоки, собственно говоря, наверно LuciferMoscow более прав...
Например, ранние версии жавы использовали некие green threads и вроде мапили свои потоки на нативные.
А для некоторых ОС и процессы являются (могут являтся) высокоуровневой настройкой.
P.S. Поправьте меня если я неправ, такое весьма вероятно. Память штука хитрая.
Здравствуйте, mik1, Вы писали:
M>>>1. Что такое поток, процесс? Чем они отличаются? LM>>В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п. M>Не услышал ответа на вопрос что такое поток и процесс.
Я это сформулировать не могу M>Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой.
Знал, но не догадался бы такое сформулировать.
А выделенное ИМХО не совсем верно.
M>>>5. Atomic-функции. Что это такое, как их использовать. LM>>Знаю, что такое название не вспомню. Нужны для "быстрого"(по сравнению с различными локерами) и threadsafety изменения данных M>Нужны они, по делу, только для реализации lock-free алгоритмов. Тут, кстати, сразу нужно задать вопрос, а гарантированно ли они выполняют свою задачу.
ИМХО, да.
Здравствуйте, LuciferMoscow, Вы писали:
M>>Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой. LM>Знал, но не догадался бы такое сформулировать. LM>А выделенное ИМХО не совсем верно.
Ну формально я могу передать ссылку на стековую переменную в другой поток. Но вот разумно ли это делать???
Здравствуйте, LM_S, Вы писали:
M>>>>1. Что такое поток, процесс? Чем они отличаются? LM>>>В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п.
M>>Не услышал ответа на вопрос что такое поток и процесс. Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой.
LM_>Чисто для поддержания дискуссии: LM_>В POSIX описаны процессы и потоки, собственно говоря, наверно LuciferMoscow более прав...
Так, но не понял, в чем Люцифер более прав.
LM_>Например, ранние версии жавы использовали некие green threads и вроде мапили свои потоки на нативные.
Да. Как и Erlang. Я это упоминал в корневом посте.
LM_>А для некоторых ОС и процессы являются (могут являтся) высокоуровневой настройкой.
Хм... А можете привести пример ОС, где процессы являются не надстройкой, т.е. являются единицами, с которыми работает планировщик ОС? Мне самому для кругозора интересно. Очень желательно с ссылкой на источник.
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, LuciferMoscow, Вы писали:
M>>>Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой. LM>>Знал, но не догадался бы такое сформулировать. LM>>А выделенное ИМХО не совсем верно.
M>Ну формально я могу передать ссылку на стековую переменную в другой поток. Но вот разумно ли это делать???
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, LM_S, Вы писали:
M>>>>>1. Что такое поток, процесс? Чем они отличаются? LM>>>>В одном процессе — 1 и более потоков. Куча у потоков(по умолчанию) одна и т.п.
M>>>Не услышал ответа на вопрос что такое поток и процесс. Про память достаточно было бы сказать, что она между потоками одного процесса разделяема (доступна) вся, кроме стеков потоков. Хотел бы услышать, что ОС планирует именно потоки, а процессы являются только высокоуровневой надстройкой.
LM_>>Чисто для поддержания дискуссии: LM_>>В POSIX описаны процессы и потоки, собственно говоря, наверно LuciferMoscow более прав... M>Так, но не понял, в чем Люцифер более прав.
В том что его определение достаточное и не содержит ошибок. ОС планирует и потоки и процессы, выбирая (обычно) конкретный процесс и поток,
где процесс естественным образом связан с потоком. Но информация, относящаяся к процессу в целом, используется. Никто не мешает планировщику
сначала спланировать процессы, а для процесса — потоки.
Если не въедаться, то ясно, что человек разницу понимает... просто не все сразу сказал.
LM_>>Например, ранние версии жавы использовали некие green threads и вроде мапили свои потоки на нативные. M>Да. Как и Erlang. Я это упоминал в корневом посте.
Это лишь к тому, что потоки бывают ОСовые
LM_>>А для некоторых ОС и процессы являются (могут являтся) высокоуровневой настройкой. M>Хм... А можете привести пример ОС, где процессы являются не надстройкой, т.е. являются единицами, с которыми работает планировщик ОС? Мне самому для кругозора интересно. Очень желательно с ссылкой на источник.
Чего-то я не понял... точнее понял, что ОС таких не знаю.
Это не очень эффективно наверно. (Выносить выбор потока еще куда-то что зависит от процесса)
К сожалению, усиленно дискуссию продолжать не могу, очень это утомительно.