Здравствуйте, 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 делается легко и непринужденно, если окружение не мешает.
Ну удачи тебе провести апгрейд на средненьком проекте в несколько десятков человеколет в крупной конторе. Когда сидишь в мелкой конторе и сам себе голова перекомпилировать конечно не проблема Мы же про реальный мир говорим, нет?
Здравствуйте, gandjustas, Вы писали:
G>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
И зачем писать такой код?
G>Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.
Зачем вы используете во многопоточном окружении непотокобезопасные объекты? Потокобезопасная обертка пишется за пять минут, проблемы с многопоточностью решает навсегда.
Здравствуйте, Lloyd, Вы писали:
U>>если не лочиться на объекты и не пользоваться гениальными МСовскими паттернами, вроде SyncRoot, то им просто неоткуда взяться. L>у вас не шарятся данные между потоками?
Что значит шарятся? Используются несколькими потоками? Естественно используются. А что есть какие-то проблемы с написанием объекта данных гарантирующего свое потокобезопасное использование?
MM>Сдуреть. А если еще подумать о том, что нужен не Multithreaded environment developer, а .Net developer, то трудно представить, какой объем данных надо держать в голове, чтобы не плавать во всем этом.
я включал(постараля) в этот список устоявшиеся знания\методики — нет причин ожидать каких-то изменений в них ближайшие 5 лет. В основном там все стабильно последние лет 10-15.
Изначально я вписал туда
-HPC(CUDA\OpenCL), но они только развиваются и неизвестно что будет в ближайшие 3года. Там используеются очень интересные подходы
-алгоритмы на внешней памяти — но там тоже возможны серьезные изменения, т.к. SSD дает на 2порядка меньше время доступа и стремительно развивается
-библиотечно-технологический инструменарий типа plinq, mpi, TPL etc.
что-то еще было, не помню
Да, для быстро устаревающих знаний — это конечно большой объем, для фундаментальных — скорее маленький
Здравствуйте, 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
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>Такой код может вызвать дедлок независимо от a и b. Причем вложенные локи могут быть совсем неочевидны, например находиться очень глубоко во вложенной функции.
U>И зачем писать такой код?
В результате развития проекта. С нуля конечно такой никогда не пишется.
G>>Часто такое возникает когда пишется сначала простой код, потом этот код запускается в нескольких потоках, потом начинает резко усложняться и внезапно возникают race-condition, которые хочется победит блокировками, а высокоуровневые блокировки тормозят систему.
U>Зачем вы используете во многопоточном окружении непотокобезопасные объекты?
Все mutable объекты по-умолчанию непотокобезопасны.
U>Потокобезопасная обертка пишется за пять минут, проблемы с многопоточностью решает навсегда.
Это как? ставить lock на каждый вызов метода? Кроме того потокобезопасность для mutable бесплатной не бывает.
И этот код выполняется в куче потоков. При этом между 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
В общем держи пирожок . Сейчас нахожусь в активной фазе поиска работы и задали на интервью этот вопрос. Боюсь если бы ты не напомнил, то сразу бы и не сообразил
Мы же про реальный мир говорим, нет?
. Сейчас нахожусь в активной фазе поиска работы и задали на интервью этот вопрос. Боюсь если бы ты не напомнил, то сразу бы и не сообразил 
