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

L>

Во-первых, метод помеченный как синхронизированный синхронизируется на объекте, которому он принадлежит, в случае instance метода (и т.д. по спецификации) а не на отдельном объекте для каждого такого метода.
L>

Во-вторых, зачем синхронизировать доступ к отдельному методу? Синхронизация необходима для предотвращения одновременного доступа к объекту, что бы не нарушить инвариантность его состояния. Если для некоторого метода необходимо синхронизировать доступ к некоторому подможеству состояния объекта (читай подможеству атрибутов) нежели в остальных методах, имеет смысл подумать о "выделении класса"!
L>[/list]

Да, не прав я, только что проверил. Экивалентны действительно, по крайней мере на винде.
Звиняюсь

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

L>Ну во первых это всего лишь инспекция, которая ищет потенциальное место ошибок. Во вторых, цитируешь — цитируй полностью. А то смысл, как-то коряжется. Там написано что и synchronized(this) и synchronized метод могут привести к возникновению дедлоков. Если какой один левый поток захватит лок для такого объекта и не отпустит, что все потоки, входящие в блоки синхронизации на этом объекте окажутся заблокированы. Но ведь это не значит, что теперь необходимо отказаться от synchronized методов. Это значит, что надо просто грамотно работать с synchronized блоками.

Я про synchronized (this)...

Спасибо

Здравствуйте, Волк-Призрак, Вы писали:

ВП>Ого! Вот это настоящие принципиальные отличия....

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

ВП>Я использую синхронизацию по классу, чтобы организовать очередь обращений клоггеру — потоки получают временой штамп, строку и объект, пишеут в StringBuffer-ы, результат своей работы подают "на конвейер" в синхронный метод, который:
ВП>[ul]
ВП>[li]Пишет строку в файл.[/li]
ВП>[li]Пишет её в консоль[/li]
ВП>[li]Отправляет её в графический логгер (swing-компонент).[/li]
ВП>[/ul]
ВП>Если бы писать в файл например не каждый раз а 1-2 раза в секунду — это ускорит работу но об "ошибке перед крахом" инфа будет утерена...

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

Спасибо!

Здравствуйте, Аноним, Вы писали:

А>теперь рассмотрим что происходит, если, как ты говоришь, блокировка накладывается только на один синхронизированный метод, а не на весь объект — дергаешь в потоке sync метод, и пока он выполняется другой метод из другого потока (по-твоему неважно уже sync метод или не sync, т.к. они не имеют отношения к блоку вызванного тобою метода) меняет данные объекта этого же объекта, т.е. данные для твоего потока становятся не актуальны. вывод допиши сам.

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

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

ВП>>Я использую синхронизацию по классу, чтобы организовать очередь обращений клоггеру — потоки получают временой штамп, строку и объект, пишеут в StringBuffer-ы, результат своей работы подают "на конвейер" в синхронный метод, который:
ВП>>[ul]
ВП>>[li]Пишет строку в файл.[/li]
ВП>>[li]Пишет её в консоль[/li]
ВП>>[li]Отправляет её в графический логгер (swing-компонент).[/li]
ВП>>[/ul]
ВП>>Если бы писать в файл например не каждый раз а 1-2 раза в секунду — это ускорит работу но об "ошибке перед крахом" инфа будет утерена...

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

Эээ.... А какая разница, очередь чего: сообщений в конвейере, или потоков к синхронному методу? А такая, что за явной очередью надо ухаживать, появляется промежуточный шаг (взять всю очередь), и мне думается, лучше пусть ось занимается синхронизацией, чем я