R>для синьора нужен solid background и правильный ход мыслей

+1

R>ниже очень примерный список тем для самопроверки

А тут ты по-моему переборщил все-таки. Часть вопросов нормальная, а часть не очень. Какие-то гонки, модели памяти, лок-фри, императивный вс функциональный. Вот ни разу не видел чтобы в реальном коде был дедлок. Ни разу не видел гонок. Обычно как? Нужно вставить данные в какую-то коллекш в одном потоке и снять в другом. Лок фри тоже ни разу не видел. И что ты имеешь в виду под имеративным и функциональным и task based parallelism — без понятия. Может знаю это под другими названиями.

В прочем есть надежда что с толковым интервьюером может получиться интересная беседа. Идиот же доведет это все до маразма.

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

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

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

унылое задротство, простите

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

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa
Сдуреть. А если еще подумать о том, что нужен не Multithreaded environment developer, а .Net developer, то трудно представить, какой объем данных надо держать в голове, чтобы не плавать во всем этом.

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

Внимание! Этого человека слушать не надо. Это профессиональный читатель но никак не программист. Хинт: смотрим сертификаты данного товарища которые он разрекламировал в своей подписи. Складывается впечатление что данный товарищ решил сдать все тесты которые есть у Майкрософта.

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

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

для синьора нужен solid background и правильный ход мыслей
ниже очень примерный список тем для самопроверки

-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
-базовые сведения о типичных багах — дедлоки, контеншн, гонки
-multitaskinig preemptive\non preemptive, scheduling
-модели памяти, лок-фри
-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

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

G>Спроси вообще про средства асинхронности и многопоточности. Если останется на уровне Thread.Start и ThreadPool, то низачот. Должен знать про Task Parallel Library, SynchronizationContext, Dispatcher, BackgroundWorker.

По поводу последнего, имхо, вы зря. Может человек только сервер-сайд и писал, откуда он может знать про классы, специфичные для клиентского кода?

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

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
Спроси какие проблемы были и как решались. А то вопросами про инновационные TPL и байндинги найдёшь новичка с хорошей памятью, проштудировавшего очередную книжку.

ОК>>Вообще тут происходит какая-то подмена понятий. Сеньйором считается тот кто зазубрил кучу ненужного хлама а не тот кто может простым и понятным способом решить задачу.

L>Я бы не сказал, что то, что перечислил gandjustas — ненужный хлам. Зря вы так.

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

И потом, технологии меняются. То что сегодня может быть hot завтра потеряет всякую актуальность.

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

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

R>>ниже очень примерный список тем для самопроверки

ОК>Часть вопросов нормальная, а часть не очень. Какие-то гонки, модели памяти, лок-фри, императивный вс функциональный. Вот ни разу не видел чтобы в реальном коде был дедлок.

Дорогой rsdn team, сделай пожалуйста оценку

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

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

Если действительно senior, то не надо долбать вопросами чем отличается ThreadStartDelegate от ParametrizedThreadStartDelegate.
Спроси вообще про средства асинхронности и многопоточности. Если останется на уровне Thread.Start и ThreadPool, то низачот. Должен знать про Task Parallel Library, SynchronizationContext, Dispatcher, BackgroundWorker. Если расскажет про Rx и async, то будет плюсом.
Также должен ориентировать в паттернах асинхронных вызовов, вроде APM (BeginXXX\EndXXX) и EAP (XXXAsync\XXXCompleted\Cancel).

Что касается WCF, то для уровня Senior, кроме стандартных байндингов и контрактов надо спрашивать про MessageContracts, коллбеки, сессии, инстансы, режимы многопоточности, webhttpbinding, REST (odata).

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

На счет WCF ничего не скажу но по многопоточности вопросы могут быть независимы от языка и платформы. Мое видение:

1) Разница между процесом и потоком. Когда лучше использовать процесы и потоки
2) Context switch и состояние потока
3) Благодаря чему ОС может давать потоку квант CPU
4) Shared data и примитивы синхронизации
5) Атомарность и как она достигается
5) Multi-core и multi-cpu машины

Ну и в качестве кода можно попросить написать (или просто поговорить) о чем-нибудь типа strtok() в плюсах или поговорить о producer-consumer в реальном контексте.

ОК>>Ты не понял пойнта. Сеньйор может и не знать всей этой фигни на интервью но в реальной задаче, если это нужно, он разберется и освоит это.
R>синьор который не знает, но разберется называется джуниор

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

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

G>>>Да ну?
G>>>Вот такое без TPL\Rx\F# легко сделать?

L>>Как из этого следует необходимость знания "SynchronizationContext, Dispatcher, BackgroundWorker"?


G>

G>Так что челендж примерно одинаковый,

Если челендж с и без — одинаковый, то кузнец, очевидно, не нужен.

G>

G>а понимать какие механизмы используются — необходимо для senior.

Цытаты себя — это конечно серьезный аргумент.

ОК>>Так и есть. Если заглянешь в транскрипт данному товарищу то увидишь что там доведенно все до маразма.
L>Почему сразу "маразм"? Может у него хобби такое.

Все может быть. Хобби с его точки зрения, маразм с моей. Когда работаешь полный рабочий день, то врядли найдется столько времени чтобы готовиться и сдавать все эти экзамены. Ну сдай ты один, два, три и гордись но не сто же? При чем там темы такие в которых у него вряд ли есть реальный опыт.

Видел я подобных читателей. Строчки кода нормально написать сами не могут, зато учат всех как программировать. Это я не о форуме а о бывших сотрудниках.

Вообще тут происходит какая-то подмена понятий. Сеньйором считается тот кто зазубрил кучу ненужного хлама а не тот кто может простым и понятным способом решить задачу.

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

U>Ежели выделенное, то я тоже за 4 года активного написания серверных приложений ни одного дедлока не видел.
Вопрос. А ты многопоточность-то видел? Или писал вебсервисы особо не задумываясь об оной?

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

HL>Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".

Хм, я такого класса тоже не знаю

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

HL>Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".

т.е. 500 млн. индусов уже знают дотнет?

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

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

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

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

G>>>>Современные инструменты позволяют не напрягаясь решать такие задачи. Senior требуется понимание механизмов, но писать на собеседовании producer-consumer queue — уже перебор.

A>>>А если FW ниже 4?
G>>1)Апгрейд до .NET 4
G>>2)Rx, который содержит backport tpl на .NET 3.5

A>>>Хорошо конечно, когда MS за тебя все проблемы решает, но по личным ощущениям на четверку переведены от силы 10% проектов.
G>>Апгрейд на .NET4 делается легко и непринужденно, если окружение не мешает.

A>Ну удачи тебе провести апгрейд на средненьком проекте в несколько десятков человеколет в крупной конторе.
Не перживай за меня. Перетягивал два проекта, один с 1.1 на 2.0, это было тяжко, но в конце-концов работало Другой с 2.0 на 3.5, тоже ниче так.

A>Когда сидишь в мелкой конторе и сам себе голова перекомпилировать конечно не проблема Мы же про реальный мир говорим, нет?
А что есть "реальный мир"? Поменять в настройках проектов 3.5 на 4.0 скомпилировать, прогнать тесты
не отвалилось? — рефакторить
отвалилось — смотреть ошибки, по возможности править.

Если что сборки .NET 3.5 отлично грузятся в домен 4.0

Тут как на войне — главное не ссать.

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

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

G>>Спроси вообще про средства асинхронности и многопоточности. Если останется на уровне Thread.Start и ThreadPool, то низачот. Должен знать про Task Parallel Library, SynchronizationContext, Dispatcher, BackgroundWorker.

L>По поводу последнего, имхо, вы зря. Может человек только сервер-сайд и писал, откуда он может знать про классы, специфичные для клиентского кода?

Не важно где и что он писал, важно что будет писать.

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

L>>По поводу последнего, имхо, вы зря. Может человек только сервер-сайд и писал, откуда он может знать про классы, специфичные для клиентского кода?

G>Не важно где и что он писал, важно что будет писать.

Взаимодействие с UI — имхо далеко не самый большой челленж в написании многопоточных приложений.

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

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

L>>>По поводу последнего, имхо, вы зря. Может человек только сервер-сайд и писал, откуда он может знать про классы, специфичные для клиентского кода?

G>>Не важно где и что он писал, важно что будет писать.

L>Взаимодействие с UI — имхо далеко не самый большой челленж в написании многопоточных приложений.

Да ну?
Вот такое без TPL\Rx\F# легко сделать?

Вариант ахинхронного кода на севрере не сильно отличается при тех же инструментах.

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

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

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

L>>>Взаимодействие с UI — имхо далеко не самый большой челленж в написании многопоточных приложений.

G>>Да ну?
G>>Вот такое без TPL\Rx\F# легко сделать?

L>Как из этого следует необходимость знания "SynchronizationContext, Dispatcher, BackgroundWorker"?

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

O>"Какими способами можно запустить другой поток в дотнете". Пока еще ни один индусик не ответил, хотя если судить по резюме, то все тимлиды, ну или на худой конец сеньоры с 10+ годами опыта в дотнете.

Технически это System.Threading.Thread класс который сведется к CreateThread(). Все остальное — надстройки. Если же ты имеешь в виду как задействовать другой поток в своем приложении, то на ум сразу приходит выше-упомянутый класс, BackgroundWorker и асинхронные делегаты, которые, в свою очередь, задействуют thread pool. Возможно есть еще что-то в более поздних версиях .NET-a что на ум не приходит, но пофиг.

А теперь, будь добр, скажи что ты ожидаешь услышать на этот вопрос и какие именно способы ты сам задействовал в своем коде? Если ты вообще пишешь код.

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

Да нет, я понял без кода. Ну тут самое место для семафора чтобы дать знать что в коллекшне что-то появилось и критикал секшн/мьютекс для защиты этой коллекции при снятии и вставке. Я думал ты нечто другое имеешь в виду.

A>Другой вариант того же самого задания — есть три потока, которые выполняют длительные операции и в конце возвращают значения. Как сделать так, чтобы значения вернулись в строго определенной последовательности.

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

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

ОК>Здравствуйте, gandjustas, Вы писали:

ОК>Внимание! Этого человека слушать не надо. Это профессиональный читатель но никак не программист. Хинт: смотрим сертификаты данного товарища которые он разрекламировал в своей подписи. Складывается впечатление что данный товарищ решил сдать все тесты которые есть у Майкрософта.

У тебя видимо нет ни одного сданного экзамена раз ты так говоришь. Зависть помноженная на глупость — страшная вещь.

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

A>Здравствуйте, Олег К., Вы писали:

A>>>Попроси написать простую producer/consumer queue с гарантированым порядком исполнения или любой другой пример с нужной последовательностью обработки потоков. Если напишет плавно перейди к возможным дедлокам в этом коде. Это так для затравки.

ОК>>Что значит "гарантированный порядок исполнения" и "нужная последовательность обработки потоков?" Может я неправильно понимаю тебя но ты сейчас говоришь о задачах которые являются чисто последовательными, т.е. потоки тут не нужны. Будь добр, elaborate и приведи более конкретный пример задачи.

A>Вкратце, два потока, один на добавление, другой на чтение, порядок исполнения не гарантирован. То, что мне встречалось — реализация очереди где поток зависал, ожидая элемента в очереди, а добавляющий не мог добавить, т.к была блокировка. Нужно было исправить код, что бы чтение гарантированно происходило после добавления и не было дедлоков. Код сейчас лень писать, а пример у меня не сохранился.
BlockingCollection<T> и пример из MSDN

A>Другой вариант того же самого задания — есть три потока, которые выполняют длительные операции и в конце возвращают значения. Как сделать так, чтобы значения вернулись в строго определенной последовательности.

Используя Task&lt;T&gt;

task1.Result
task2.Result
task3.Result

Современные инструменты позволяют не напрягаясь решать такие задачи. Senior требуется понимание механизмов, но писать на собеседовании producer-consumer queue — уже перебор.

G>У тебя видимо нет ни одного сданного экзамена раз ты так говоришь.

Ни одного кроме дурацкого брэйнбенча и ему подобных которые мне давали рекрутеры. Но они мне и нафиг не нужны.

G>Зависть помноженная на глупость — страшная вещь.

Да я даже как-то и не задумывался о каких-то сертификатах и тестах. Где тут зависть?

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

ОК>>Часть вопросов нормальная, а часть не очень. Какие-то гонки, модели памяти, лок-фри, императивный вс функциональный. Вот ни разу не видел чтобы в реальном коде был дедлок.

Z>Дорогой rsdn team, сделай пожалуйста оценку

А что у тебя такую оценку вызвало? Ежели выделенное, то я тоже за 4 года активного написания серверных приложений ни одного дедлока не видел. Т.к. если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.

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

U>Т.к. если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.

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

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

G>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.

И зачем писать такой код?

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

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

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


U>

U>object readLockObj;
U>object updateLockObj;
U>Result result;

U>public Result Read()
U>{
U>  lock (readLockObj)
U>  {
U>    return InnerRead();
U>  }
U>}

U>Result InnerRead()
U>{
U>  return result;
U>}

U>public void Update(Func<Result, Result> executter)
U>{
U>  lock (updateLockObj)
U>  {
U>    Result result = executter(InnerRead());
U>    lock (readLockObj)
U>      this.result = result;
U>  }
U>}
U>

readLockObj, updateLockObj static вроде как надо

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

R>Изначально я вписал туда
R>-HPC(CUDA\OpenCL), но они только развиваются и неизвестно что будет в ближайшие 3года. Там используеются очень интересные подходы
R>-алгоритмы на внешней памяти — но там тоже возможны серьезные изменения, т.к. SSD дает на 2порядка меньше время доступа и стремительно развивается
R>-библиотечно-технологический инструменарий типа plinq, mpi, TPL etc.
R>что-то еще было, не помню
R>Да, для быстро устаревающих знаний — это конечно большой объем, для фундаментальных — скорее маленький
Я согласен, что всё это вещи — достойные внимания и изучения. И список действительно хороший для образования. Но как вопросы для интервью, они больше подходят кандидату, у которого многопочность — предметная область. Если же речь идет о .Net Developer-е, то, помимо multithreading, там еще стока всего, что требовать столь углубленных знаний мне кажется излишеством. Представь, человека будут гонять по базовой библиотеке, по UI, по средствам доступа к данным. Если и там выдвинуть подобные требования, то уж не знаю. Классно, конечно, найти такого программера, но только на очень большие деньги.

ОК>>1) Разница между процесом и потоком. Когда лучше использовать процесы и потоки
A>Можно поподробнее, что хочется услышать на выделенное? А то какое-то получается.

Вообще-то это стандартный вопрос который больше задается программистам под Юникс.

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

С другой стороны ресурсы в каждом процесе ограничены. Мы можем открыть столько-то хэндлов/дескрипторов/сокетов, у нас ограниченно виртуальное адресное пространство и т.д. Поэтому если нам надо "много какого-то ресурса" (та же память, например) то нужно задейстовать несколько процесов.

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

Ну и все в таком же духе, примерно.

G>Какие-то не связанные утверждения. Получается что человек может знать и при этом пихать все новомодные фичи, он одновременно джуниор и сеньйор?

В том-то и дело что синьйор не станет пихать в проект все что ни попадя.

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

Знания фундаментальные. Опыт какой-то есть. Свое подозрение я высказал выше.

G>Да ну?

G>

G>//Поток 1
G>lock(a)
G>{
G>    lock(b)
G>    {
G>    }
G>}

G>//Поток 2
G>lock(b)
G>{
G>    lock(a)
G>    {
G>    }
G>}
G>

От этого примера веет книжностью за версту, дорогой читатель.

Вообще-то потоки обычно основываются на одной thread function и поэтому локать ресурсы они будут в одном и том же порядке полюбому.

G>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.

Могут но если у тебя потоки основаны на одной thread function, такого не случится. И потом, будь добр, приведи примеры ресурсов которые надо локать во вложенном порядке и держать столь продолжительное время?

Обычно-таки побыстрому вставляешь/снимаешь данные с коллекшна и все.

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

Это какие-то фантазии тут.

G>ЗЫ. Вот теперь и мне хочется оценку

Мне тоже что-то захотелась эта оценка.

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

HL>>Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".
JR>Хм, я такого класса тоже не знаю

Даже и не знаю, что ответить. Ну наверное то, что мы тебе не сможем предложить работу на 100 000 долларов в год.

Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

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

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
"Какими способами можно запустить другой поток в дотнете". Пока еще ни один индусик не ответил, хотя если судить по резюме, то все тимлиды, ну или на худой конец сеньоры с 10+ годами опыта в дотнете.

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

ET>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

Попроси написать простую producer/consumer queue с гарантированым порядком исполнения или любой другой пример с нужной последовательностью обработки потоков. Если напишет плавно перейди к возможным дедлокам в этом коде. Это так для затравки.

A>Попроси написать простую producer/consumer queue с гарантированым порядком исполнения или любой другой пример с нужной последовательностью обработки потоков. Если напишет плавно перейди к возможным дедлокам в этом коде. Это так для затравки.

Можно использовать и BlockingCollection<T>.

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

L>>Взаимодействие с UI — имхо далеко не самый большой челленж в написании многопоточных приложений.

G>Да ну?
G>Вот такое без TPL\Rx\F# легко сделать?

Как из этого следует необходимость знания "SynchronizationContext, Dispatcher, BackgroundWorker"?

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

R>Здравствуйте, e.thrash, Вы писали:

ET>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

R>для синьора нужен solid background и правильный ход мыслей
R>ниже очень примерный список тем для самопроверки

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

Указание WCF в заголовке коворит больше об io-bound, чем о compute-bound.

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

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

Красавец, все правильно написал.

О! Супер!!

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

Правда я всегда думал что l3 это и есть ram, но возможно за три года без embedded отстал...

R>>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>>-multitaskinig preemptive\non preemptive, scheduling
R>>-модели памяти, лок-фри
R>>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

A>Попроси написать простую producer/consumer queue с гарантированым порядком исполнения или любой другой пример с нужной последовательностью обработки потоков. Если напишет плавно перейди к возможным дедлокам в этом коде. Это так для затравки.

Что значит "гарантированный порядок исполнения" и "нужная последовательность обработки потоков?" Может я неправильно понимаю тебя но ты сейчас говоришь о задачах которые являются чисто последовательными, т.е. потоки тут не нужны. Будь добр, elaborate и приведи более конкретный пример задачи.

ET>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
A>Спроси какие проблемы были и как решались. А то вопросами про инновационные TPL и байндинги найдёшь новичка с хорошей памятью, проштудировавшего очередную книжку.

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

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

A>>Попроси написать простую producer/consumer queue с гарантированым порядком исполнения или любой другой пример с нужной последовательностью обработки потоков. Если напишет плавно перейди к возможным дедлокам в этом коде. Это так для затравки.

ОК>Что значит "гарантированный порядок исполнения" и "нужная последовательность обработки потоков?" Может я неправильно понимаю тебя но ты сейчас говоришь о задачах которые являются чисто последовательными, т.е. потоки тут не нужны. Будь добр, elaborate и приведи более конкретный пример задачи.

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

ОК>Ну и в качестве кода можно попросить написать (или просто поговорить) о чем-нибудь типа strtok() в плюсах или поговорить о producer-consumer в реальном контексте.

Имелось в виду поговорить о недостатках текущей strtok() в многопоточном приложении и написать/поговорить о ее thread-safe эквиваленте.

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

ОК>Внимание! Этого человека слушать не надо. Это профессиональный читатель но никак не программист. Хинт: смотрим сертификаты данного товарища которые он разрекламировал в своей подписи. Складывается впечатление что данный товарищ решил сдать все тесты которые есть у Майкрософта.

Вы говорите так, как будто это что-то плохое.

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

G>Здравствуйте, Олег К., Вы писали:

ОК>>Здравствуйте, gandjustas, Вы писали:

ОК>>Внимание! Этого человека слушать не надо. Это профессиональный читатель но никак не программист. Хинт: смотрим сертификаты данного товарища которые он разрекламировал в своей подписи. Складывается впечатление что данный товарищ решил сдать все тесты которые есть у Майкрософта.

G>У тебя видимо нет ни одного сданного экзамена раз ты так говоришь. Зависть помноженная на глупость — страшная вещь.
Ууууу как всё запущенно-то.

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

ОК>А теперь, будь добр, скажи что ты ожидаешь услышать на этот вопрос
Примерно то, что ты ответил.

ОК>и какие именно способы ты сам задействовал в своем коде? Если ты вообще пишешь код.
Практически все с первой версии дотнета.

L>Вы говорите так, как будто это что-то плохое.

Так и есть. Если заглянешь в транскрипт данному товарищу то увидишь что там доведенно все до маразма.

ОК>>А теперь, будь добр, скажи что ты ожидаешь услышать на этот вопрос
O>Примерно то, что ты ответил.

Неужто ни один индус не назвал эти три штуки? По-моему ты принижаешь их. Хоть их тут и ругают во главе с тобой, не все из них такие дурные.

ОК>>и какие именно способы ты сам задействовал в своем коде? Если ты вообще пишешь код.
O>Практически все с первой версии дотнета.

Ты как-то ловко ушел от ответа. Перечисли конкретные классы и прочее что ты задействовал реально.

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

L>>Вы говорите так, как будто это что-то плохое.

ОК>Так и есть. Если заглянешь в транскрипт данному товарищу то увидишь что там доведенно все до маразма.

Почему сразу "маразм"? Может у него хобби такое.

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

ОК>Вообще тут происходит какая-то подмена понятий. Сеньйором считается тот кто зазубрил кучу ненужного хлама а не тот кто может простым и понятным способом решить задачу.

Я бы не сказал, что то, что перечислил gandjustas — ненужный хлам. Зря вы так.

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

ОК>Неужто ни один индус не назвал эти три штуки? По-моему ты принижаешь их. Хоть их тут и ругают во главе с тобой, не все из них такие дурные.
Издеваешься? Лучшие индусы выдавали и мямлили "нууу ээээ thread.start", после чего замолкали. Про пул потоков (после наводящих вопросов) слышало краем уха, ну может 5% индусиков, из них я припомню может одного или двух, которые знали, что это такое. Вопрос про асинхронные делегаты вгонял всех в дедлок, про который тоже слышали единицы.
На самом деле удивляться тут не стоит, 99% индусиков — клепают странички на асп.нет и про многопоточность читали в каком-то глубоком детстве.

ОК>Ты как-то ловко ушел от ответа. Перечисли конкретные классы и прочее что ты задействовал реально.
Из реальных проектов
Thread
ThreadPool
Control.Begin/EndInvoke
BackgroundWorker
Async delegates
Async WCF, both client and server side
RIA Service, only async ops

Дергал за яйки, но пока не юзал Parallel Extensions. Но у меня специфика такая, если говорить про дотнет, то было много winforms/silverlight/wpf проектов, плюс сишный бэкграунд c winapi. Было, конечно, полно и асп.нет проектов, но радости от них я не испытывал.

ОК>>Неужто ни один индус не назвал эти три штуки? По-моему ты принижаешь их. Хоть их тут и ругают во главе с тобой, не все из них такие дурные.
O>Издеваешься? Лучшие индусы выдавали и мямлили "нууу ээээ thread.start", после чего замолкали. Про пул потоков (после наводящих вопросов) слышало краем уха, ну может 5% индусиков, из них я припомню может одного или двух, которые знали, что это такое. Вопрос про асинхронные делегаты вгонял всех в дедлок, про который тоже слышали единицы.
O>На самом деле удивляться тут не стоит, 99% индусиков — клепают странички на асп.нет и про многопоточность читали в каком-то глубоком детстве.

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

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

ОК>Ну я такое же могу и сказать о русских.
Я не могу. Ибо собеседовал толпу русских и индусов. У русских более-менее неплохо, хотя бывают еще те экземпляры.

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

ОК>Имелось в виду поговорить о недостатках текущей strtok() в многопоточном приложении и написать/поговорить о ее thread-safe эквиваленте.
Мы еще о дотнете говорим?

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

G>>У тебя видимо нет ни одного сданного экзамена раз ты так говоришь.

ОК>Ни одного кроме дурацкого брэйнбенча и ему подобных которые мне давали рекрутеры.

Ну ты сравнил мужской половой орган с пальцем. Попробуй для начала хотя бы один MCPD сдать.

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

L>Здравствуйте, Олег К., Вы писали:

L>>>Вы говорите так, как будто это что-то плохое.

ОК>>Так и есть. Если заглянешь в транскрипт данному товарищу то увидишь что там доведенно все до маразма.

L>Почему сразу "маразм"? Может у него хобби такое.

Работа у меня такая. Я тренер и чтобы читать курсы надо иметь соответствующую квалификацию.

ОК>>Ни одного кроме дурацкого брэйнбенча и ему подобных которые мне давали рекрутеры.
G>Ну ты сравнил мужской половой орган с пальцем. Попробуй для начала хотя бы один MCPD сдать.

Не я а ты. Я просто сказал что за тесты брал и все. Мне эти сертификаты нафиг не упали.

G>Работа у меня такая. Я тренер и чтобы читать курсы надо иметь соответствующую квалификацию.

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

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

G>>Работа у меня такая. Я тренер и чтобы читать курсы надо иметь соответствующую квалификацию.

ОК>Ну я понял что ты не пишешь код и не копаешься в существующем.
Ну ты неправильно понял

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

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

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

ОК>>>Часть вопросов нормальная, а часть не очень. Какие-то гонки, модели памяти, лок-фри, императивный вс функциональный. Вот ни разу не видел чтобы в реальном коде был дедлок.

Z>>Дорогой rsdn team, сделай пожалуйста оценку

U>А что у тебя такую оценку вызвало? Ежели выделенное, то я тоже за 4 года активного написания серверных приложений ни одного дедлока не видел. Т.к. если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.

Да ну?

//Поток 1
lock(a)
{
    lock(b)
    {
    }
}

//Поток 2
lock(b)
{
    lock(a)
    {
    }
}

Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.

ЗЫ. Вот теперь и мне хочется оценку

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

U>если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.

у вас не шарятся данные между потоками?

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

G>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
G>Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.

Уроки чтения на rsdn:

если не лочиться на объекты

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

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

G>>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
G>>Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.

L>Уроки чтения на rsdn:
L>

L>если не лочиться на объекты

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

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

A>>Другой вариант того же самого задания — есть три потока, которые выполняют длительные операции и в конце возвращают значения. Как сделать так, чтобы значения вернулись в строго определенной последовательности.

ОК>А это зачем? Пытаюсь увидеть практическую ценность но на ум ничего не приходит. Сделать можно но нужды особой не вижу на данный момент. Нужно рассматривать конкретную задачу.

IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.

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

R>для синьора нужен solid background и правильный ход мыслей
R>ниже очень примерный список тем для самопроверки

R>-базовые сведения об объектах синхронизации критикал секшны, семафоры, барьеры, спин вэйты\локи, SWMR
R>-базовые сведения о типичных багах — дедлоки, контеншн, гонки
R>-multitaskinig preemptive\non preemptive, scheduling
R>-модели памяти, лок-фри
R>-базовые представления о различных подходах — императивный vs функциональный, task based paralelism, асинхронная обработка, параллелизм в декларативных моделях (plinq, partitioning, SQL)
R>-базовые сведения об апааратной реализации, ассоциативность и когерентность кэшэй, латентность l1\l2\l3\ram, hyper threading, numa

Хорошие вопросы, кроме пожалуй частично последних двух. Главное, что бы вопросы задавались не для самоутверждения интревьирующего (а приведенный список вызывает такие опасения). И считаю моветоном задавать вопросы, которые в реальной работе на проекте не понадобятся. Ну и задавать не все подряд, а пару-тройку.

Признавайтесь, много кто видел в реальном проекте всяких мемори барьеров?

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

ET>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?

ОК>На счет WCF ничего не скажу но по многопоточности вопросы могут быть независимы от языка и платформы. Мое видение:

ОК>1) Разница между процесом и потоком. Когда лучше использовать процесы и потоки

Можно поподробнее, что хочется услышать на выделенное? А то какое-то получается.

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

G>Современные инструменты позволяют не напрягаясь решать такие задачи. Senior требуется понимание механизмов, но писать на собеседовании producer-consumer queue — уже перебор.

А если FW ниже 4? Хорошо конечно, когда MS за тебя все проблемы решает, но по личным ощущениям на четверку переведены от силы 10% проектов.

А писать на собеседовании такой простейший код — то что доктор прописал. Код на 10 строк, нет вызовов каких-то зубодробительных методов с кучей параметров и сам по себе пример покрывает несколько смежных областей.

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

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

G>>Современные инструменты позволяют не напрягаясь решать такие задачи. Senior требуется понимание механизмов, но писать на собеседовании producer-consumer queue — уже перебор.

A>А если FW ниже 4?
1)Апгрейд до .NET 4
2)Rx, который содержит backport tpl на .NET 3.5


A>Хорошо конечно, когда MS за тебя все проблемы решает, но по личным ощущениям на четверку переведены от силы 10% проектов.
Апгрейд на .NET4 делается легко и непринужденно, если окружение не мешает.

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

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

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

G>>>Современные инструменты позволяют не напрягаясь решать такие задачи. Senior требуется понимание механизмов, но писать на собеседовании producer-consumer queue — уже перебор.

A>>А если FW ниже 4?
G>1)Апгрейд до .NET 4
G>2)Rx, который содержит backport tpl на .NET 3.5

A>>Хорошо конечно, когда MS за тебя все проблемы решает, но по личным ощущениям на четверку переведены от силы 10% проектов.
G>Апгрейд на .NET4 делается легко и непринужденно, если окружение не мешает.

Ну удачи тебе провести апгрейд на средненьком проекте в несколько десятков человеколет в крупной конторе. Когда сидишь в мелкой конторе и сам себе голова перекомпилировать конечно не проблема Мы же про реальный мир говорим, нет?

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

U>>если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.
L>у вас не шарятся данные между потоками?

Что значит шарятся? Используются несколькими потоками? Естественно используются. А что есть какие-то проблемы с написанием объекта данных гарантирующего свое потокобезопасное использование?

MM>Сдуреть. А если еще подумать о том, что нужен не Multithreaded environment developer, а .Net developer, то трудно представить, какой объем данных надо держать в голове, чтобы не плавать во всем этом.
я включал(постараля) в этот список устоявшиеся знания\методики — нет причин ожидать каких-то изменений в них ближайшие 5 лет. В основном там все стабильно последние лет 10-15.

Изначально я вписал туда
-HPC(CUDA\OpenCL), но они только развиваются и неизвестно что будет в ближайшие 3года. Там используеются очень интересные подходы
-алгоритмы на внешней памяти — но там тоже возможны серьезные изменения, т.к. SSD дает на 2порядка меньше время доступа и стремительно развивается
-библиотечно-технологический инструменарий типа plinq, mpi, TPL etc.
что-то еще было, не помню

Да, для быстро устаревающих знаний — это конечно большой объем, для фундаментальных — скорее маленький

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

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

G>>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.

U>И зачем писать такой код?

В результате развития проекта. С нуля конечно такой никогда не пишется.

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

U>Зачем вы используете во многопоточном окружении непотокобезопасные объекты?
Все mutable объекты по-умолчанию непотокобезопасны.

U>Потокобезопасная обертка пишется за пять минут, проблемы с многопоточностью решает навсегда.
Это как? ставить lock на каждый вызов метода? Кроме того потокобезопасность для mutable бесплатной не бывает.


Яркий пример:

obj.Read(/*...*/)
//много кода
obj.Update(/*...*/)

И этот код выполняется в куче потоков. При этом между read и update не должно происходить update из других потоков.

Можно конечно просто повесить критическую секцию на этот код, но тогда фактически он превратится в однопоточный.
Можно задействовать reader-writer lock, но он не сильно поможет, так как вызов read должен ставить updatelock.

Короче в этом случае проблема на уровне синхронизации не решается, надо что-то другое придумывать.

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

U>>>если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться.
L>>у вас не шарятся данные между потоками?

U>Что значит шарятся? Используются несколькими потоками? Естественно используются. А что есть какие-то проблемы с написанием объекта данных гарантирующего свое потокобезопасное использование?

Без локов и иных объектов синхронизации? Может быть у вас и нет проблем, но лично я не в курсе, как писать такие "объекты". Просвятите?

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

A>>>>Хорошо конечно, когда MS за тебя все проблемы решает, но по личным ощущениям на четверку переведены от силы 10% проектов.
G>>>Апгрейд на .NET4 делается легко и непринужденно, если окружение не мешает.

A>>Ну удачи тебе провести апгрейд на средненьком проекте в несколько десятков человеколет в крупной конторе.
G>Не перживай за меня. Перетягивал два проекта, один с 1.1 на 2.0, это было тяжко, но в конце-концов работало Другой с 2.0 на 3.5, тоже ниче так.

Да я тоже перегонял. Ровно с такими же проблемами как у тебя.

A>>Когда сидишь в мелкой конторе и сам себе голова перекомпилировать конечно не проблема Мы же про реальный мир говорим, нет?
G>А что есть "реальный мир"? Поменять в настройках проектов 3.5 на 4.0 скомпилировать, прогнать тесты
G>не отвалилось? — рефакторить
G>отвалилось — смотреть ошибки, по возможности править.

Не реальный мир это десятки, если не сотни серверов, аппликуха 24/7, куча админов их обслуживающая, манагер с бюджетом, которому надо внятно доказать, что кроме понтов даст переход на новый фреймворк и почему это не может подождать пару лет. Да и вообще зачем ему на это нужно выделять пять-шесть человекомесяцев. С технической точки зрения серьезных проблем после FW 2.0 действительно не много.

G>Если что сборки .NET 3.5 отлично грузятся в домен 4.0

G>Тут как на войне — главное не ссать.

Тут главное понимать, что программер не пуп земли.

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

G>>Тут как на войне — главное не ссать.
A>Тут главное понимать, что программер не пуп земли.

Ну если есть необходимость писать параллельный\асинхронный код, то почему бы не вложить немного и перейти на новую версию. По сути это смена библиотеки и не более и решение чисто техническое, так как .NET бесплатен. Это не апгрейд платной СУБД.

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

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

G>>>Тут как на войне — главное не ссать.
A>>Тут главное понимать, что программер не пуп земли.

G>Ну если есть необходимость писать параллельный\асинхронный код, то почему бы не вложить немного и перейти на новую версию. По сути это смена библиотеки и не более и решение чисто техническое, так как .NET бесплатен. Это не апгрейд платной СУБД.

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

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

L>Без локов и иных объектов синхронизации? Может быть у вас и нет проблем, но лично я не в курсе, как писать такие "объекты". Просвятите?

Почему без локов-то? С локами, но только на внутренний приватный lockObj.

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

L>>Без локов и иных объектов синхронизации? Может быть у вас и нет проблем, но лично я не в курсе, как писать такие "объекты". Просвятите?

U>Почему без локов-то? С локами, но только на внутренний приватный lockObj.

Все на один? Такой подход называется "помахай ядрам ручкой".

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

L>>Я бы не сказал, что то, что перечислил gandjustas — ненужный хлам. Зря вы так.

ОК>Ты не понял пойнта. Сеньйор может и не знать всей этой фигни на интервью но в реальной задаче, если это нужно, он разберется и освоит это. Этот чувак же срежет его на интервью.

И что по вашему мнению нужно спрашивать сеньера по предмету многопоточности?

G>Если что сборки .NET 3.5 отлично грузятся в домен 4.0
не подскажешь кстати где про это толково и не шибко многословно написано? (пойдет и книга и статья)

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

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

G>И этот код выполняется в куче потоков. При этом между read и update не должно происходить update из других потоков.
G>Можно конечно просто повесить критическую секцию на этот код, но тогда фактически он превратится в однопоточный.

Здесь, да, у объекта будет два lockObj, соответственно при написании внутренностей такого объекта нужно быть внимательным. Но правило вроде простое, если метод читает состояние, то он использует только readLockObj, если метод модифицирует состояние, то на всю транзакцию вешается updateLockObj и на момент собственно модификации состояния класса используется readLockObj. Такого правила сложно придерживаться? Использование объекта будет по-прежнему полностью безопасным.

object readLockObj;
object updateLockObj;
Result result;

public Result Read()
{
  lock (readLockObj)
  {
    return InnerRead();
  }
}

Result InnerRead()
{
  return result;
}

public void Update(Func<Result, Result> executter)
{
  lock (updateLockObj)
  {
    Result result = executter(InnerRead());
    lock (readLockObj)
      this.result = result;
  }
}

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

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

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

G>>>>Тут как на войне — главное не ссать.
A>>>Тут главное понимать, что программер не пуп земли.

G>>Ну если есть необходимость писать параллельный\асинхронный код, то почему бы не вложить немного и перейти на новую версию. По сути это смена библиотеки и не более и решение чисто техническое, так как .NET бесплатен. Это не апгрейд платной СУБД.

A>Дык вот и надо взвесить все за и против и не ломиться сломя голову.
"Против" может быть только одно — что-то поломается после перехода. Но пока не попробуешь — не узнаешь. Кроме того мигрировать все проекты сразу на 4.0 необязательно, можно сделать это постепенно.

A>Рано или поздно все равно перейдут, но можно например совместить с крупным релизом. Все очень индивидуально. На 3.5 перешло уже подавляющее большинство, потихонечку так же перейдут и на 4.0. Только программер с его знаниями и новый функционал нужен сегодня, а переход на 4.0 будет только послезавтра.
И послезавтра нового программера нанимать? В чем профит? Программер, особенно senior, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

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

G>Если что сборки .NET 3.5 отлично грузятся в домен 4.0

В общем держи пирожок . Сейчас нахожусь в активной фазе поиска работы и задали на интервью этот вопрос. Боюсь если бы ты не напомнил, то сразу бы и не сообразил

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

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

G>>И этот код выполняется в куче потоков. При этом между read и update не должно происходить update из других потоков.
G>>Можно конечно просто повесить критическую секцию на этот код, но тогда фактически он превратится в однопоточный.

U>Здесь, да, у объекта будет два lockObj, соответственно при написании внутренностей такого объекта нужно быть внимательным. Но правило вроде простое, если метод читает состояние, то он использует только readLockObj, если метод модифицирует состояние, то на всю транзакцию вешается updateLockObj и на момент собственно модификации состояния класса используется readLockObj. Такого правила сложно придерживаться? Использование объекта будет по-прежнему полностью безопасным.

U>

U>object readLockObj;
U>object updateLockObj;
U>Result result;

U>public Result Read()
U>{
U>  lock (readLockObj)
U>  {
U>    return InnerRead();
U>  }
U>}

U>Result InnerRead()
U>{
U>  return result;
U>}

U>public void Update(Func<Result, Result> executter)
U>{
U>  lock (updateLockObj)
U>  {
U>    Result result = executter(InnerRead());
U>    lock (readLockObj)
U>      this.result = result;
U>  }
U>}
U>

фактически весь рабочий код будет выполняться в update, то есть считай однопоточно.

Кстати такой сценарий очень легко получить если взять обычный synchrinized queue и попытаться превратить его в reliable queue, то есть поток должен сигнализировать очереди о том что он закончил обработку элемента иначе элемент должен быть возвращен назад в очередь.

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

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

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

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

G>>>>>Тут как на войне — главное не ссать.
A>>>>Тут главное понимать, что программер не пуп земли.

G>>>Ну если есть необходимость писать параллельный\асинхронный код, то почему бы не вложить немного и перейти на новую версию. По сути это смена библиотеки и не более и решение чисто техническое, так как .NET бесплатен. Это не апгрейд платной СУБД.

A>>Дык вот и надо взвесить все за и против и не ломиться сломя голову.
G>"Против" может быть только одно — что-то поломается после перехода. Но пока не попробуешь — не узнаешь. Кроме того мигрировать все проекты сразу на 4.0 необязательно, можно сделать это постепенно.

Ну и? Вот и придется код писать старыми методами. А если что-то поломается (хз, говнокода что ли на свете мало), то там и недели могут уйти на поправить. Не откатить назад, а именно поправить.

A>>Рано или поздно все равно перейдут, но можно например совместить с крупным релизом. Все очень индивидуально. На 3.5 перешло уже подавляющее большинство, потихонечку так же перейдут и на 4.0. Только программер с его знаниями и новый функционал нужен сегодня, а переход на 4.0 будет только послезавтра.
G>И послезавтра нового программера нанимать? В чем профит? Программер, особенно senior, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

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

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



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

а можно пояснить что тут является непотокобезопасным объектом?

//Поток 1
lock(a)
{
    lock(b)
    {
    }
}

//Поток 2
lock(b)
{
    lock(a)
    {
    }
}

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

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

L>>Без локов и иных объектов синхронизации? Может быть у вас и нет проблем, но лично я не в курсе, как писать такие "объекты". Просвятите?

U>Почему без локов-то? С локами, но только на внутренний приватный lockObj.

общий lockObj на оба lock?

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

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

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

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

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

G>>>>>>Тут как на войне — главное не ссать.
A>>>>>Тут главное понимать, что программер не пуп земли.

G>>>>Ну если есть необходимость писать параллельный\асинхронный код, то почему бы не вложить немного и перейти на новую версию. По сути это смена библиотеки и не более и решение чисто техническое, так как .NET бесплатен. Это не апгрейд платной СУБД.

A>>>Дык вот и надо взвесить все за и против и не ломиться сломя голову.
G>>"Против" может быть только одно — что-то поломается после перехода. Но пока не попробуешь — не узнаешь. Кроме того мигрировать все проекты сразу на 4.0 необязательно, можно сделать это постепенно.

A>Ну и? Вот и придется код писать старыми методами. А если что-то поломается (хз, говнокода что ли на свете мало), то там и недели могут уйти на поправить. Не откатить назад, а именно поправить.
Я же говорю — надо попробовать. Уверен что больше половины проектов нормально перейдут с 3.5 на 4.0

A>>>Рано или поздно все равно перейдут, но можно например совместить с крупным релизом. Все очень индивидуально. На 3.5 перешло уже подавляющее большинство, потихонечку так же перейдут и на 4.0. Только программер с его знаниями и новый функционал нужен сегодня, а переход на 4.0 будет только послезавтра.
G>>И послезавтра нового программера нанимать? В чем профит? Программер, особенно senior, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

A>Зачем нового. Нынешний или знает или подтянется.
Ага, а потом уйдет на новое место работы

A>Я же тебе привел пример, когда знание нового функционала ничем не поможет до перехода, а переход еще не скоро.
С чего ты взял что не поможет? Я же тебе говорю что проще реализовать подмножество функционала из новой версии, чем пытаться решать некоторые задачи "влоб".

A>Так что умение писать под старый фреймворк необходимо.
Ты подменяешь понятия. Я не говорил что не нужно умение писать под старый, я говорю что нужно умение писать под новый.

Я бы сейчас не стал брать программистов, которые не знают ничего про .net4, даже если писать придется под 3.5. А у меня сейчас именно такая ситуация, так как основное поле работы — sharepoint 2010, он под .NET3.5 написан.

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

G>фактически весь рабочий код будет выполняться в update, то есть считай однопоточно.

Т.е. в основном состояние объекта используется для модификации этого самого состояния, а использований состояния объекта с другой целью практически нет? Какая-то вещь в себе получается. Но если так, то, да, как не извращайтесь работать в основном будет один поток, чудес не бывает. Впрочем если повезет, то можно распараллелить код промежуточных вычислений (тот который между Read и Update).

зы
Если не секрет, какая у вас специфика задач, что подобные вопросы являются актуальными?

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

U>>Почему без локов-то? С локами, но только на внутренний приватный lockObj.
P>общий lockObj на оба lock?

Обычно на объект заводится один lockObj и все lock'и делаются на него. Если критично подвисание чтения на тяжелых модификациях, то используются два lockObj'а, как показано здесь: http://rsdn.ru/forum/job/4254057.1.aspx

Автор: Undying
Дата: 29.04.11

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

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

G>>фактически весь рабочий код будет выполняться в update, то есть считай однопоточно.

U>Т.е. в основном состояние объекта используется для модификации этого самого состояния, а использований состояния объекта с другой целью практически нет? Какая-то вещь в себе получается. Но если так, то, да, как не извращайтесь работать в основном будет один поток, чудес не бывает. Впрочем если повезет, то можно распараллелить код промежуточных вычислений (тот который между Read и Update).

U>зы
U>Если не секрет, какая у вас специфика задач, что подобные вопросы являются актуальными?

Ничего особенного. Я такое на практике видел, когда обычную очередь, с помощтю которой общались producer_ы и consumer_ы, попытались превратить в reliable queue. Так как consumer мог иногда падать и некоторые "сообщения" оставались необработанными.

Просто яркий пример, который не решается допиливанием самой queue.

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

P>readLockObj, updateLockObj static вроде как надо

Зачем статик? Мы ж состояние экземпляра делаем потокобезопасным, а не статическое состояние.

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

G>>Если что сборки .NET 3.5 отлично грузятся в домен 4.0
R>не подскажешь кстати где про это толково и не шибко многословно написано? (пойдет и книга и статья)

Честно говоря нет, я про фичу давно узнал и проблем с этим не возникало.

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

G>>Если что сборки .NET 3.5 отлично грузятся в домен 4.0
R>не подскажешь кстати где про это толково и не шибко многословно написано? (пойдет и книга и статья)

а с чем у вас проблемы?

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

A>>Ну и? Вот и придется код писать старыми методами. А если что-то поломается (хз, говнокода что ли на свете мало), то там и недели могут уйти на поправить. Не откатить назад, а именно поправить.
G>Я же говорю — надо попробовать. Уверен что больше половины проектов нормально перейдут с 3.5 на 4.0

А я тебе повторяю, что желание левой пятки прораммера для перехода может не хватить

A>>>>Рано или поздно все равно перейдут, но можно например совместить с крупным релизом. Все очень индивидуально. На 3.5 перешло уже подавляющее большинство, потихонечку так же перейдут и на 4.0. Только программер с его знаниями и новый функционал нужен сегодня, а переход на 4.0 будет только послезавтра.
G>>>И послезавтра нового программера нанимать? В чем профит? Программер, особенно senior, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

A>>Зачем нового. Нынешний или знает или подтянется.
G>Ага, а потом уйдет на новое место работы

Зачем, если его все на старом устраивает?

A>>Я же тебе привел пример, когда знание нового функционала ничем не поможет до перехода, а переход еще не скоро.
G>С чего ты взял что не поможет? Я же тебе говорю что проще реализовать подмножество функционала из новой версии, чем пытаться решать некоторые задачи "влоб".

Ну всю подветку твержу. Самый тупой сценарий — слова манагера "Никаких переходов до релиза 1 ноября". Или кроме тебя никто в 4-й FW не вникал. Причин может быть куча.

A>>Так что умение писать под старый фреймворк необходимо.
G>Ты подменяешь понятия. Я не говорил что не нужно умение писать под старый, я говорю что нужно умение писать под новый.

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

G>Я бы сейчас не стал брать программистов, которые не знают ничего про .net4, даже если писать придется под 3.5. А у меня сейчас именно такая ситуация, так как основное поле работы — sharepoint 2010, он под .NET3.5 написан.

Ну и можешь потерять пул вполне вменяемых людей. У меня например в резюме упомянания четвертого FW нет, т.к. проектов на нем не было, а упомянание в скилсете, того что реально не использовал попахивает индусятиной. Хотя если задают по четрверки вопросы стараюсь отвечать.

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

G>Ничего особенного. Я такое на практике видел, когда обычную очередь, с помощтю которой общались producer_ы и consumer_ы, попытались превратить в reliable queue. Так как consumer мог иногда падать и некоторые "сообщения" оставались необработанными.

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

G>Просто яркий пример, который не решается допиливанием самой queue.

Если я правильно понял задачу, то допиливанием очереди она решается, хоть и достаточно шамански.

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

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

U>>>Почему без локов-то? С локами, но только на внутренний приватный lockObj.
P>>общий lockObj на оба lock?

U>Обычно на объект заводится один lockObj и все lock'и делаются на него. Если критично подвисание чтения на тяжелых модификациях, то используются два lockObj'а, как показано здесь: http://rsdn.ru/forum/job/4254057.1.aspx

Автор: Undying
Дата: 29.04.11

один lockObj на класс?
даже если в классе есть 2 lock-а в 2 статичных методах?

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

G>Не перживай за меня. Перетягивал два проекта, один с 1.1 на 2.0, это было тяжко, но в конце-концов работало Другой с 2.0 на 3.5, тоже ниче так.
С первого на второй проблемы были. Ибо менялась серьезно версия рантайма. С двушки на три — ноль проблем, рантайм тот же. С трехи на четыре — проблем никаких, хоть версию и поменяли, но реально мало что поменяли в самом рантайме.
В последних двух случаях (2->3->4) больше было политических проблем и доказывания, что ничего не будет и усе в порядке.

P>а с чем у вас проблемы?
пока ни с чем. Интересно и опасаюсь что они там поднимут 2 домена и будут маршалить между ними данные через ремотинг

L>И что по вашему мнению нужно спрашивать сеньера по предмету многопоточности?

Да тут где-то ниже ответил. Вообще моя точка зрения прослеживается на протяжении этих постов.

A>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.

Может лучше пересмотреть дизайн? В данном случает пусть сами потоки пишут рекорды в файл по своему смещению.

L>>И что по вашему мнению нужно спрашивать сеньера по предмету многопоточности?
ОК>Да тут где-то ниже ответил. Вообще моя точка зрения прослеживается на протяжении этих постов.

Вот этот пост

Автор: MxMsk
Дата: 29.04.11

хорошо дает rationale за моим предложением.

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

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

A>>>Ну и? Вот и придется код писать старыми методами. А если что-то поломается (хз, говнокода что ли на свете мало), то там и недели могут уйти на поправить. Не откатить назад, а именно поправить.
G>>Я же говорю — надо попробовать. Уверен что больше половины проектов нормально перейдут с 3.5 на 4.0

A>А я тебе повторяю, что желание левой пятки прораммера для перехода может не хватить

Ты не повторяй, ты обосновывай. Я пока не вижу причин не переходить на .NET4. если окружение не мешает.

A>>>>>Рано или поздно все равно перейдут, но можно например совместить с крупным релизом. Все очень индивидуально. На 3.5 перешло уже подавляющее большинство, потихонечку так же перейдут и на 4.0. Только программер с его знаниями и новый функционал нужен сегодня, а переход на 4.0 будет только послезавтра.
G>>>>И послезавтра нового программера нанимать? В чем профит? Программер, особенно senior, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

A>>>Зачем нового. Нынешний или знает или подтянется.
G>>Ага, а потом уйдет на новое место работы

A>Зачем, если его все на старом устраивает?
На новом банально больше денег предложат за новые знания.

A>>>Я же тебе привел пример, когда знание нового функционала ничем не поможет до перехода, а переход еще не скоро.
G>>С чего ты взял что не поможет? Я же тебе говорю что проще реализовать подмножество функционала из новой версии, чем пытаться решать некоторые задачи "влоб".

A>Ну всю подветку твержу. Самый тупой сценарий — слова манагера "Никаких переходов до релиза 1 ноября".
Хреновая ситуация когда менеджер не понимает, но при этом принимает решение. Я таких менеджеров быстро на место ставили или валил из такой конторы.

A>Или кроме тебя никто в 4-й FW не вникал. Причин может быть куча.
Причина только одна: незнание. И ты предлагаешь не проверять знание новых версий на собеседовании.


A>>>Так что умение писать под старый фреймворк необходимо.
G>>Ты подменяешь понятия. Я не говорил что не нужно умение писать под старый, я говорю что нужно умение писать под новый.

A>Да тоже спорно, но допустимо. Не каждый готов тратить собственное время на изучение нового функционала, но прекрасно освоит все новое, когда встанет такая задача.
Когда задача встанет осваивать обычно уже поздно, уже писать надо.
И кстати ты сам себе противоречишь. Ведь старые подходы после обновления версии работают и необученные программисты скорее будут фигачить код по старому, чем изучать что-то новое, учитывая выделенное выше.

Такой подход культивирует незнание.

G>>Я бы сейчас не стал брать программистов, которые не знают ничего про .net4, даже если писать придется под 3.5. А у меня сейчас именно такая ситуация, так как основное поле работы — sharepoint 2010, он под .NET3.5 написан.

A>Ну и можешь потерять пул вполне вменяемых людей.
Программистов sharepoint настолько мало, что у меня в городе я всех лично знаю. Среди них нету людей, которые не знают .NET4

A>У меня например в резюме упомянания четвертого FW нет, т.к. проектов на нем не было, а упомянание в скилсете, того что реально не использовал попахивает индусятиной. Хотя если задают по четрверки вопросы стараюсь отвечать.
Есть такая штука как обратная совместимость. Если человек знает .NET4, то он нормально сможет писать и на 3.5, обратное в общем случае неверно. Поэтому твоя позиция мне совершенно непонятна.

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

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

G>>Ничего особенного. Я такое на практике видел, когда обычную очередь, с помощтю которой общались producer_ы и consumer_ы, попытались превратить в reliable queue. Так как consumer мог иногда падать и некоторые "сообщения" оставались необработанными.

U>Т.е. нужно было забирать сообщения из очереди, обработку их производить в произвольном порядке, но результат записывать в порядке очереди? Если обработка сообщения провалилась, то заставлять ждать результаты обработки последующих сообщений до тех пор, пока все-таки предыдущее сообщение будет обработано?
Ну да, обычно reliable-очереди это не совсем fifo очереди.

G>>Просто яркий пример, который не решается допиливанием самой queue.
U>Если я правильно понял задачу, то допиливанием очереди она решается, хоть и достаточно шамански.
Нет, она решается написанием другой очереди. Это как бы совсем не создание synchronized обертки как говорил один из участников дискуссии.

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

ОК>>>1) Разница между процесом и потоком. Когда лучше использовать процесы и потоки
A>>Можно поподробнее, что хочется услышать на выделенное? А то какое-то получается.

ОК>Вообще-то это стандартный вопрос который больше задается программистам под Юникс.

ОК>Тут обычно хотят увидеть как человек мыслит. Потоки находятся в одном процесе так что данные между потоками шэраются легко. Процесы же имеют каждый свое виртуальное адресное пространство, поэтому данные шэрать уже посложнее. Надо задействовать шаред мемори, например что накладывает свои сложности.

ОК>С другой стороны ресурсы в каждом процесе ограничены. Мы можем открыть столько-то хэндлов/дескрипторов/сокетов, у нас ограниченно виртуальное адресное пространство и т.д. Поэтому если нам надо "много какого-то ресурса" (та же память, например) то нужно задейстовать несколько процесов.

ОК>Ну и еще один пойнт который хотят услышать это фолт толеранс. Если в многопоточной системе исполняется в каком-то потоке код который крэшает весь процес (баг), то все, систем остановлена в то время как многопроцесная система может продолжать работу "потеряв" один процес.

ОК>Ну и все в таком же духе, примерно.

Тогда стоит задавать вопрос, в чем разница между процессами и потоками, написанными на С в unix
Учитывая что данная тема про .NET там другие правила игры, у java свои. Вообще такие низкоуровневые вещи получаются сильно платформозависимыми, чтобы их спрашивать у любого человека.

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

A>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.

ОК>Может лучше пересмотреть дизайн? В данном случает пусть сами потоки пишут рекорды в файл по своему смещению.

А если рекорды переменного размера?

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

ОК>>>Ты не понял пойнта. Сеньйор может и не знать всей этой фигни на интервью но в реальной задаче, если это нужно, он разберется и освоит это.
R>>синьор который не знает, но разберется называется джуниор

ОК>Наоборот, синьйор который пихает все новомодные фичи и технологии в проект называется джуниор. Тот кто знает что есть такие-то и такие вещи, какие возможны проблемы и как решить задачу так, что решение будет понято любым, называется синьйором.

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

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

A>>А я тебе повторяю, что желание левой пятки прораммера для перехода может не хватить

G>Ты не повторяй, ты обосновывай. Я пока не вижу причин не переходить на .NET4. если окружение не мешает.

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

A>>>>Зачем нового. Нынешний или знает или подтянется.
G>>>Ага, а потом уйдет на новое место работы

A>>Зачем, если его все на старом устраивает?
G>На новом банально больше денег предложат за новые знания.

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

A>>>>Я же тебе привел пример, когда знание нового функционала ничем не поможет до перехода, а переход еще не скоро.
G>>>С чего ты взял что не поможет? Я же тебе говорю что проще реализовать подмножество функционала из новой версии, чем пытаться решать некоторые задачи "влоб".

A>>Ну всю подветку твержу. Самый тупой сценарий — слова манагера "Никаких переходов до релиза 1 ноября".
G>Хреновая ситуация когда менеджер не понимает, но при этом принимает решение. Я таких менеджеров быстро на место ставили или валил из такой конторы.

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

A>>Или кроме тебя никто в 4-й FW не вникал. Причин может быть куча.
G>Причина только одна: незнание. И ты предлагаешь не проверять знание новых версий на собеседовании.

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

A>>>>Так что умение писать под старый фреймворк необходимо.
G>>>Ты подменяешь понятия. Я не говорил что не нужно умение писать под старый, я говорю что нужно умение писать под новый.

Оно не первостепенное.

A>>Да тоже спорно, но допустимо. Не каждый готов тратить собственное время на изучение нового функционала, но прекрасно освоит все новое, когда встанет такая задача.
G>Когда задача встанет осваивать обычно уже поздно, уже писать надо.

Только не говори мне, что на понимание новых фич малтитредига займет какое-то значительное время.

G>И кстати ты сам себе противоречишь. Ведь старые подходы после обновления версии работают и необученные программисты скорее будут фигачить код по старому, чем изучать что-то новое, учитывая выделенное выше.

Рано или поздно придется. Если не начнут это уже другая проблема, никак не связаная с требованием переходить на новый FW как можно быстрее и тем более не брать на работу.

G>Такой подход культивирует незнание.

Такой подход отражает реальность и здравый смысл.

G>>>Я бы сейчас не стал брать программистов, которые не знают ничего про .net4, даже если писать придется под 3.5. А у меня сейчас именно такая ситуация, так как основное поле работы — sharepoint 2010, он под .NET3.5 написан.

A>>Ну и можешь потерять пул вполне вменяемых людей.
G>Программистов sharepoint настолько мало, что у меня в городе я всех лично знаю. Среди них нету людей, которые не знают .NET4

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

A>>У меня например в резюме упомянания четвертого FW нет, т.к. проектов на нем не было, а упомянание в скилсете, того что реально не использовал попахивает индусятиной. Хотя если задают по четрверки вопросы стараюсь отвечать.
G>Есть такая штука как обратная совместимость. Если человек знает .NET4, то он нормально сможет писать и на 3.5, обратное в общем случае неверно. Поэтому твоя позиция мне совершенно непонятна.

Это из чего следует? Вообще мимо. Как знание тасков подтвердает знание более низкоуровневых техник? Тех же самых Wait/Pulse.

A>>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.
ОК>>Может лучше пересмотреть дизайн? В данном случает пусть сами потоки пишут рекорды в файл по своему смещению.
G>А если рекорды переменного размера?

И? Все равно продумай код так чтобы потоки знали по какому смещению им надо писать. Да и вообще тут решений масса. Необязательно стопориться на одном.

G>Тогда стоит задавать вопрос, в чем разница между процессами и потоками, написанными на С в unix
G>Учитывая что данная тема про .NET там другие правила игры, у java свои. Вообще такие низкоуровневые вещи получаются сильно платформозависимыми, чтобы их спрашивать у любого человека.

А тут ты прав скорее всего но, замечу, что это вопросы больше по фундаменту.

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

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

A>>>А я тебе повторяю, что желание левой пятки прораммера для перехода может не хватить

G>>Ты не повторяй, ты обосновывай. Я пока не вижу причин не переходить на .NET4. если окружение не мешает.

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

Слово "может" говорит о предположении, а не об обосновании.

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

A>>>Или кроме тебя никто в 4-й FW не вникал. Причин может быть куча.
G>>Причина только одна: незнание. И ты предлагаешь не проверять знание новых версий на собеседовании.
A>Я предлагаю не делать из этого самоцель и уж точно не отказывать грамотному спецу если он не знает чего-то, что в данный момент не используется.
А кто про самоцель говорит? Помоему ты начал разговор с того что сказал что могут современные знания не понадобиться.

A>>>>>Так что умение писать под старый фреймворк необходимо.
G>>>>Ты подменяешь понятия. Я не говорил что не нужно умение писать под старый, я говорю что нужно умение писать под новый.
A>Оно не первостепенное.
Умение писать под новый FW, включает в себя умение писать под старый FW почти всюду. Так что ты сам себе противоречишь.

A>>>Да тоже спорно, но допустимо. Не каждый готов тратить собственное время на изучение нового функционала, но прекрасно освоит все новое, когда встанет такая задача.
G>>Когда задача встанет осваивать обычно уже поздно, уже писать надо.
A>Только не говори мне, что на понимание новых фич малтитредига займет какое-то значительное время.
Я тебе скажу что понимание и правильное применение dynamic займет оооооочень значительное время.

G>>И кстати ты сам себе противоречишь. Ведь старые подходы после обновления версии работают и необученные программисты скорее будут фигачить код по старому, чем изучать что-то новое, учитывая выделенное выше.
A>Рано или поздно придется.
По какой причины? Я из твоих слов такой причины не вижу.

A>Если не начнут это уже другая проблема, никак не связаная с требованием переходить на новый FW как можно быстрее и тем более не брать на работу.
Ну так нужно не допускать проблем

G>>Такой подход культивирует незнание.
A>Такой подход отражает реальность и здравый смысл.
То есть культивирует незнание

G>>>>Я бы сейчас не стал брать программистов, которые не знают ничего про .net4, даже если писать придется под 3.5. А у меня сейчас именно такая ситуация, так как основное поле работы — sharepoint 2010, он под .NET3.5 написан.

A>>>Ну и можешь потерять пул вполне вменяемых людей.
G>>Программистов sharepoint настолько мало, что у меня в городе я всех лично знаю. Среди них нету людей, которые не знают .NET4
A>Ну вот, чего я и опасался. Ты судишь по наверняка маленькому городку.
Больше миллиона, ты считаешь это маленький город?

A>Я же тебе сразу сказал, я не про те ситуации, где программист царь и бог, увольняет менеджеров, сам деплоит и устанавливает апдейты на сервера.
Это ты сам выдумываешь. Я такого не видел ни разу. В мою бытность рядовым программистом я production сервер не видел ни разу.

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

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

G>>Какие-то не связанные утверждения. Получается что человек может знать и при этом пихать все новомодные фичи, он одновременно джуниор и сеньйор?
ОК>В том-то и дело что синьйор не станет пихать в проект все что ни попадя.
Счегобы?

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

A>>>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.
ОК>>>Может лучше пересмотреть дизайн? В данном случает пусть сами потоки пишут рекорды в файл по своему смещению.
G>>А если рекорды переменного размера?

ОК>И? Все равно продумай код так чтобы потоки знали по какому смещению им надо писать. Да и вообще тут решений масса. Необязательно стопориться на одном.

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

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

ОК>От этого примера веет книжностью за версту, дорогой читатель.
ОК>Вообще-то потоки обычно основываются на одной thread function и поэтому локать ресурсы они будут в одном и том же порядке полюбому.
Во-первых никто не говорит что это будут одинаковые thread function. Во-вторых гарантировать порядок локов не получится никак на любом нетривиальном коде иначе локи получатся слишком низкогранулярны и код фактически будет в один поток исполняться.

G>>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
ОК>Могут но если у тебя потоки основаны на одной thread function, такого не случится. И потом, будь добр, приведи примеры ресурсов которые надо локать во вложенном порядке и держать столь продолжительное время?
ОК>Обычно-таки побыстрому вставляешь/снимаешь данные с коллекшна и все.
В параллельной ветке писал.

res.Read(/*...*/)
//lot of code
res.Update(/*...*/)

Этот код исполняется несколькими потоками. Между read и update не должен происходить update из другого потока.
И как тут "побыстрому" сделать то что ты говоришь?

G>>Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.
ОК>Это какие-то фантазии тут.
Это правда жизни

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

G>>Какие-то не связанные утверждения. Получается что человек может знать и при этом пихать все новомодные фичи, он одновременно джуниор и сеньйор?

ОК>В том-то и дело что синьйор не станет пихать в проект все что ни попадя.

Если ему будет выгодно поддерживать резюме up-to-date — будет и еще как. Resume-driven development

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

A>>>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.
ОК>>>Может лучше пересмотреть дизайн? В данном случает пусть сами потоки пишут рекорды в файл по своему смещению.
G>>А если рекорды переменного размера?

ОК>И? Все равно продумай код так чтобы потоки знали по какому смещению им надо писать. Да и вообще тут решений масса. Необязательно стопориться на одном.

Ты издеваешься? Это реализуется потоками и там 1-2 строчки кода. Зачем огород городить?

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

ET>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
O>"Какими способами можно запустить другой поток в дотнете". Пока еще ни один индусик не ответил, хотя если судить по резюме, то все тимлиды, ну или на худой конец сеньоры с 10+ годами опыта в дотнете.

Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".

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

ET>>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
A>>Спроси какие проблемы были и как решались. А то вопросами про инновационные TPL и байндинги найдёшь новичка с хорошей памятью, проштудировавшего очередную книжку.

ОК>+100 но только, все-таки, нужно дополнительно спросить о базовых понятиях и попросить написать немного кода.
Это произойдёт (или не произойдёт само собой при обсуждении проблем.

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

HL>Здравствуйте, Jolly Roger, Вы писали:

HL>>>Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".
JR>>Хм, я такого класса тоже не знаю

HL>Даже и не знаю, что ответить. Ну наверное то, что мы тебе не сможем предложить работу на 100 000 долларов в год.

Да ладно, "не сможем"...Не хотите, знаю я вас! А всё жадность ваша буржуйская!

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

A>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.

del3.BeginInvoke(...);
del1.BeginInvoke(...);
del2.BeginInvoke(...);

// задаем нужный порядок EndInvoke'ов
del1.EndInvoke();
del2.EndInvoke();
del3.EndInvoke();

или я чего-то не понимаю?

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

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

A>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.
AK>

AK>del3.BeginInvoke(...);
AK>del1.BeginInvoke(...);
AK>del2.BeginInvoke(...);

AK>// задаем нужный порядок EndInvoke'ов
AK>del1.EndInvoke();
AK>del2.EndInvoke();
AK>del3.EndInvoke();
AK>

AK>или я чего-то не понимаю?

Да все нормально. Есть несколько способов. Обычный вопрос — обычный ответ. А то тут уже предлагали оффсеты считать

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

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

A>>IO операции. Пишешь ты большой файл, но прежде чем записать, тебе нужно произвести расчеты. Расчеты длинные. А информация в файле должна быть строго в определенном порядке. Такого в реальной жизни пруд пруди.
AK>

AK>del3.BeginInvoke(...);
AK>del1.BeginInvoke(...);
AK>del2.BeginInvoke(...);

AK>// задаем нужный порядок EndInvoke'ов
AK>del1.EndInvoke();
AK>del2.EndInvoke();
AK>del3.EndInvoke();
AK>

AK>или я чего-то не понимаю?

Да все нормально. Есть несколько способов. Обычный вопрос — обычный ответ. А то тут уже предлагали оффсеты считать

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

A>Да все нормально. Есть несколько способов. Обычный вопрос — обычный ответ. А то тут уже предлагали оффсеты считать

в принципе да, пока все просто. а теперь привeдите свое решение для подобной очереди (queue)

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

R>синьор который не знает, но разберется называется джуниор

Не следует путать синьора программиста с синьором С++ программистом канального уровня стека TCP/IP под платформу виндоус. Это совершенно разные люди, как Маркс и Энгельс.

P.S. Блин, как задолбали эти "синьоры", в Италии, что ли, живем?
"Старший программист" это называется по-русски.

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

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

A>>Да все нормально. Есть несколько способов. Обычный вопрос — обычный ответ. А то тут уже предлагали оффсеты считать

AK>в принципе да, пока все просто. а теперь привeдите свое решение для подобной очереди (queue)

Thread.Join() или AutoResetEvent

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

A>Thread.Join() или AutoResetEvent

вроде слышал про такой метод и такой класс, но не уверен

по теме: я не понял смысла вашей задачи, потому и прошу привести решение — может быть их него пойму о чем речь. или если не трудно еще раз только популярно про задачу с "queue с гарантированым порядком исполнения"

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

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

ET>>>Какие вопросы могут показать примерный уровень по данным направлениям в на должность senior .Net developer?
O>>"Какими способами можно запустить другой поток в дотнете". Пока еще ни один индусик не ответил, хотя если судить по резюме, то все тимлиды, ну или на худой конец сеньоры с 10+ годами опыта в дотнете.

HL>Подтверждаю каждую букву. 50% индусов не могут ответить на вопрос "назовите ЛЮБОЙ класс в дотнете".

встречный вопрос: как такие индусы попадают в штаты?
тут многие из России толковые не могут уехать

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

S>встречный вопрос: как такие индусы попадают в штаты?
Индусы они такие, пробивные и пронырливые. Пока русские плачут о жизни, индусы лезут во все возможные и невозможные щели. Типичный пример — индусские жены. Русские сидят по домам и охают, что работы не найти приличной, а индусы своих отправляют на курсы тестеров и глядишь, через год она уже сидит в офисе и кнопки жмет за 60-80К.

Кроме того, поедет ли толковый русский на 30-40К в год гарантированного рабства лет на 10? Несколько лет назад народ на 80-90 звали с гринкой через 1-3 года и народ нос воротил.