Yuri Khomich,
LCR>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>О как. И в чем же там грабли?
В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Yuri Khomich,
LCR>>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>>О как. И в чем же там грабли?
LCR>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Дедлок можно сделать и синхронизируясь по приватному объекту.
Кроме того, возможность синхронизироваться по самому объекту может быть частью публичного интерфейса. Например, в Java перебрать элементы синхронизированной коллекции можно (и нужно) так:
List list = Collections.synchronizedList(other);
// . . .synchronized (list) {
for (Object item : list) {
// . . .
}
}
Если бы методы синхронизированной коллекции были синхронизированы не по this, а по какому-то приватному объекту, то невозможно было бы гарантировать, что коллекция не изменится во время перебора ее элементов.
Можно, конечно, было бы сделать синхронизируемый объект публичным, но в таком случае непонятно чем такой код
synchronized (list.syncRoot()) {
// . . .
}
лучше такого
synchronized (list) {
// . . .
}
поскольку все равно доступиться к синхронизированному объекту опять же может кто угодно.
Здравствуйте, Геннадий Васильев, Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ГВ>Если ты уже делишь языки на "основные" и "альтернативные" — это уже ошибочная постановка вопроса. Посему предложу тебе другую методику. В начале, пожалуй, математика в объёме первых 3-х курсов любого вуза. Это — минимум. Дальше в некотором роде смесь: системное программирование, формальные языки и построение компиляторов, дискретная математика, основы электроники, вопросы связанные с искусственным интеллектом. Присоединюсь к тем, кто советовал SICP и добавлю сюда ещё дядьку Кнута. Потом — применение тех или иных языков для определённых задач. Ну и в процессе уже определишься, что к чему и почему, и откуда и куда у чего ноги растут.
ГВ>А так... Ну скажут тебе, что, к примеру, Lisp полезно знать. А почему? Его же относительно редко применяют. Потому что Пол Грэхем о нём балладу спел? Так баллады много о чём пели! Что ж теперь?
ГВ>Так что, копай, а там вопросы подобные онтопику сами собой отпадут.
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>>>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
YK>>О как. И в чем же там грабли?
LCR>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Здравствуйте, Yuri Khomich, Вы писали:
YK>Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Ну, наверное, имеется в виду, что в случае синхронайзед методов — шанс получить дедлок выше.
И вообще, имхо, это странно — иметь возможность использовать любой объект в системе в качестве монитора.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, VladD2, Вы писали:
VD>>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) R>В чем собственно недостаток? Если уж грабельный разговор... заодно расскажите, используете ли вы модификатор new в C#?
).
VD>> или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). R>Возвращение примитива по ссылке противоречит объектно-ориентированному методу. Это уже множество раз обсуждалось: передача параметра "по ссылке"
— в C# это оставили, потому на нем удобно писать в том числе и "процедурно" (к примеру, вычислители), а Java более "чистый" в этом отношении ООЯ.
Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
Однако, если говорить о Java, то ref-out в ней до сих пор не реализовано не только по "историческим причинам" и еще и потому, что ref-out параметры могут "добавить" граблей в программу.
Например, необходимость в ref-out параметрах часто демонстрируется на примере функции Swap, которая меняет значения двух переменных, передаваемых в качестве параметров.
Swap может быть реализована так:
void Swap(ref int a, ref int b)
{
int t = a;
a = b;
b = t;
}
Однако, если попытаться ею обменять значения полей некоторого объекта (в одном потоке), то другой поток может "увидеть" частично измененный объект (т.е. после "a = b" и до "b = t") и это промежуточное состояние может нарушать внутренний инвариант класса. Ситуация может быть еще более критичная, если Swap будет реализован так:
void Swap(ref int a, ref int b)
{
a ^= b;
b ^= a;
a ^= b;
}
ведь a и b могут быть индексами массива, а промежуточное значение (a ^ b) врядли будет осмысленным.
Т.е. для того, чтобы пользоваться таким Swap'ом необходимо понимать, что происходит внутри (т.е. невозможно воспринимать Swap как черный ящик) и предпринимать некотороые действия для того, чтобы избежать негативных последствий. Скажем, поместить вызовы Swap в lock блок. Кроме того, функции с ref параметрами могут возбуждать исключения, а это добавляет сложностей, поскольку в случае возникновения исключения в общем случае может потребоваться привести ref параметры в некое "разумное" значение.
Дима,
D>Дедлок можно сделать и синхронизируясь по приватному объекту.
Ну для этого стараться гораздо надо больше. Предположим, мы ссылки на приватные объекты-локи наружу нигде не выставляем — ни прямо, ни косвенно. Отсюда следует, что получить дедлок можно только получив цикл на этих локах, которые — заметим! — все перечислены в начале определения класса.
D>
D>Если бы методы синхронизированной коллекции были синхронизированы не по this, а по какому-то приватному объекту, то невозможно было бы гарантировать, что коллекция не изменится во время перебора ее элементов.
Здесь ты немножечко прав. Но совсем немножечко.
Во-первых, компилятор мог бы обеспечить (а может обеспечивает, кстати) атомарность участка от входа в функцию до первого оператора. Или более слабое утверждение — если первый оператор synchronized(...). На самом деле ползать по первым стэйтментам компилятору не в первой — см. super.
D> Можно, конечно, было бы сделать синхронизируемый объект публичным,...
А во-вторых, можно было бы передавать объект синхронизации в качестве параметра конструктору:
List list = Collections.synchronizedList(other, lock);
// . . .synchronized (lock) {
for (Object item : list) {
// . . .
}
}
Yuri Khomich,
LCR>>В том, что доступ к this может иметь все, кому не лень, отсюда следует угроза дедлока. Синхронизация должна производиться по внутреннему (желательно приватному) объекту.
YK>Ничего такого отсюда не следует. С таким же успехом ты можешь получить дедлок в случае использования в качестве локов внутренних объектов, если локи берутся в неверном порядке. Ну так думать же надо.
Далеко не с таким же успехом. У приватных объектов есть (гораздо меньший) scope. Думать? Ну да, думать в любом случае надо.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Если ты уже делишь языки на "основные" и "альтернативные" — это уже ошибочная постановка вопроса. Посему предложу тебе другую методику. В начале, пожалуй, математика в объёме первых 3-х курсов любого вуза. Это — минимум. Дальше в некотором роде смесь: системное программирование, формальные языки и построение компиляторов, дискретная математика, основы электроники, вопросы связанные с искусственным интеллектом. Присоединюсь к тем, кто советовал SICP и добавлю сюда ещё дядьку Кнута. Потом — применение тех или иных языков для определённых задач. Ну и в процессе уже определишься, что к чему и почему, и откуда и куда у чего ноги растут.
Здравствуйте, fmiracle, Вы писали:
L>>А основы электроники-то зачем?
F>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер — от этого хуже не будет, а помочь иногда может
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> и добавлю сюда ещё дядьку Кнута.
А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать". Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, fmiracle, Вы писали:
L>>>А основы электроники-то зачем?
F>>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер — от этого хуже не будет, а помочь иногда может
L>Ну эдак и до квантовой механики можно опуститься.
Здравствуйте, Lloyd, Вы писали:
L>А основы электроники-то зачем?
Хотя бы для того, чтобы понимать, почему производительность не бесконечна.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, konsoletyper, Вы писали:
K>А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать".
Здесь, ИМХО, нужно добавлять: "...наконец-то".
K>Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
Естественно. А как его читать без предварительной теории графов, например?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, konsoletyper, Вы писали:
K>А то многие начинают выпендриваться и говорить "прочитай Кнута и научишься программировать". Совершенно согласен, что Кнута нужно изучать далеко не в первую очередь.
это как раз основы программирования. только читать надо в адаптированном варианте, типа "алгоритмы и структуры данных" Вирта; таких книг до фига и ещё больше
Здравствуйте, rsn81, Вы писали:
R>По-моему, "изучать" языки не делая на них конкретный проект — пустая трата времени. В университетах Object Pascal дают по нескольку лет, и то после этого человек его не знает. Полевые условия — самый верный вариант обучения... ну и икра на хлебе появится.
(Object) Pascal это отдельная сущность.
Это прародитель всех языков Паскалевской группы и базовых алгоритмов. Т.е. именно его и надо изучать — ибо сие есть база для всего остального. Тако ж Lisp и Java. Ну и С туда же.
Здравствуйте, rsn81, Вы писали:
VD>>Ява перенела довольно много граблей из С++. Например, отсуствие явного указания переопределения методов (ключевое слово override) R>В чем собственно недостаток? Если уж грабельный разговор... заодно расскажите, используете ли вы модификатор new в C#?
Понимешь ли в чем дело? Некоторые вещи для осмысления требудт нехилой подготовки и опыта. Вот чем плохи грабли одна из таких вещей. Ее очень сложно объяснить. Более того если человек не видел как можно жить по другому, то ему обычно вообще ничего объяснить нельзя. Очень редкий человек может адекватно судить о том, что он не знает, и что он не пробовл.
VD>> или отсуствие возможности явно описать, что функция возращает множество результатов (в виде кортежей или ref/out-параметров). R>Возвращение примитива по ссылке противоречит объектно-ориентированному методу. Это уже множество раз обсуждалось: передача параметра "по ссылке"
— в C# это оставили, потому на нем удобно писать в том числе и "процедурно" (к примеру, вычислители), а Java более "чистый" в этом отношении ООЯ.
Извини, а ты знаешь что такое кортежи? Или ты просто пропускаешь все назнакомые слова?
ОК, тогда ответь мне нормально ли возвращать значения из фунций запаковывая их в одноэлементные массивы или специальные обертки?
VD>> И таких проблем в ней много. R>Да?
Я не знаю, что ты радуешься. Ты явно имеешь очень небольшой кругозов в обсуждаемом вопросе. Ту плакоть надо. Или хотя бы не выступать.
Ты бы изучил 2-3 языка кроме Явы (причем не только ООП, но и поддерживающие другие парадигмы). Вот тогда бы мы с тобой компетентно поговорили бы.
VD>> C# можно считать наследником Явы в котором вычещено большинство проблем этого языка. R>Извините, но вы пока не убедили.
Кого? Тебя? Я и не соберался убеждать тебя лично. Я высказал свое мнение основанное на анализе и изучении (пускай иногда и поверхностном) этих языков. Ты же влез судить явно зная только одну Яву.
R>Да как вам угодно: на ваш список никто не посягает — просто вы сказали достаточно резкое утверждение без аргументации, вот и заинтересовало.
Я высказал свое мнение. Он не то чтобы резкое или не резкое. Оно мое. А ты пыташся его исправить так чтобы он удовлетворяло тебя. Так вот я с этим не согласен. Создавай свой список. Мой не трогай.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
Все это достадные ошибки дизайна. Но их все же не много. И их наличие никак не умоляет того факта, что ошибки дизайна Явы были проанализированы и в оснвном устранены.
D>Лично я не разделяю крайне пуристские взгляды на ref-out параметры. И считаю, что они в некоторых случаях бывают весьма полезны. Тем более, что в C#'е они реализованы, на мой взгляд, лучше, чем в C++ (например, есть разделение на ref и out (а не просто ссылка); и необходимость явно помечать ref out аргументы при вызове).
В С++ их вообще нет. За то есть указатели позволяющие эмулировать их, но эта эмуляция черевата ошибками, и опасными. Плюс явное указание этих модификаторов четко описывает намерение, а значит делает код более понятным и предсказуемым.
Но самое, что смешное, лично я соглассен, что без них можно было бы обойтись. Только не так убого как в Яве, где они просто отсуствуют, что приводит к эмуляции их совершенно уродливыми методами, а как это сделано в большинстве ФЯ — введением кортежех.
Программируя на том же Nemerle у меня даже не возникает потребности в out/ref-параметрах. Намного красивее просто возрварить кортеж с нужными данными.
D>Однако, если говорить о Java, то ref-out в ней до сих пор не реализовано не только по "историческим причинам" и еще и потому, что ref-out параметры могут "добавить" граблей в программу.
Это явное преувеличение. Скорее из-за нежелания усложнять рантайм. Вот там действительно создаются проблемы. Но опять же запрет при явной потребности фичи — это плохое решение.
D>Например, ... если попытаться ею обменять значения полей некоторого объекта (в одном потоке), то другой поток может "увидеть" частично измененный объект .... D>Т.е. для того, чтобы пользоваться таким Swap'ом необходимо понимать, что происходит внутри (т.е. невозможно воспринимать Swap как черный ящик) и предпринимать некотороые действия для того, чтобы избежать негативных последствий. Скажем, поместить вызовы Swap в lock блок.
Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении. В них проблема гонок и неатомарности функций может возникнуть где угодно и когда угодно.
И ref/out-параметры тут вообще не причем. Любой метод изменяющий более одного поля может привести к проблемам в многопоточном окружении.
Замени ref-параметр на параметр меняющий значение в ячейке массива и ты получишь полную аналогию. Собственно так в Ява и поступают. Так что можно сказать, что в Ява ref параметры реализуются паттернами.
D> Кроме того, функции с ref параметрами могут возбуждать исключения, а это добавляет сложностей, поскольку в случае возникновения исключения в общем случае может потребоваться привести ref параметры в некое "разумное" значение.
Это так же заблуждение. Ведь исключение на то и исключение, чтобы считать все вычисления неудачными. После исключения рассчитывать на корректность данных вообще нельзя. Задача обработчиков исключений как раз и заключается в приведении данных в корректное состояние.
На самом деле ref/out-параметры довольно естественны для императивных языков. Они ничего в них не нарушают. И ни к каким проблемам не приводят.
Но у них есть одна проблема — они неудобны. Или скажем, так в большинстве случаев вместо них удобнее использовать озврат множетсва значений (котреж, напимер). Такой подход решает и проблему многопточности (при условии что весь многопоточный код написан в фукнциональном стиле) решает, и просто удобен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
