Вопросы по многопоточности и WCF - О работе

Здравствуйте, 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, со знанием новшеств можно быстро подмножество библиотеки реализовать для использования в текущей версии. Так как все спецификации уже есть и ничего выдумывать не надо.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, 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).

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

Здравствуйте, 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 вроде как надо

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

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

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

Здравствуйте, 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>не подскажешь кстати где про это толково и не шибко многословно написано? (пойдет и книга и статья)

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

Здравствуйте, 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 нет, т.к. проектов на нем не было, а упомянание в скилсете, того что реально не использовал попахивает индусятиной. Хотя если задают по четрверки вопросы стараюсь отвечать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, 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

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

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

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	29.04.11 16:40
Оценка:

	От:	Abalak
	Дата:	29.04.11 16:43
	Оценка:

	От:	merge
	Дата:	29.04.11 16:57
	Оценка:

	От:	peer
	Дата:	29.04.11 17:00
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	29.04.11 17:02
Оценка:

	От:	Олег К.
	Дата:	30.04.11 03:51
	Оценка: