Здравствуйте, Blazkowicz, Вы писали:
B>Самому интересно. И все же. Когда у тебя перестанут работать пустые циклы тогда и загрузка на 100% исчезнет. Скажешь что у тебя их нет?
Здравствуйте, xBlackCat, Вы писали:
B>>Самому интересно. И все же. Когда у тебя перестанут работать пустые циклы тогда и загрузка на 100% исчезнет. Скажешь что у тебя их нет?
BC>Не знаю. Буду искать... BC>А это BC>
Я не совем точно выразился. Наверное более подходящее определение "бесполезный цикл". То есть тот цикл который выполняется во время простоя. Если у тебя система в режиме ожидания ничего не делает, то соответственно никакой код выполнятся не должен. А когда система крутит циклы в своё удовольствие даже во время ожидания данных, тогда и загрузка процессора соответствующая.
Дело в том, что notify() пробуждает первый попавшийся поток, а их может на объекте спать много. Также, по крайней мере в теории, есть случаи, когда поток может проснуться "сам по себе".
В приведённом мной коде наш поток точно проснётся и только тогда, когда хотим мы.
D>Дело в том, что notify() пробуждает первый попавшийся поток, а их может на объекте спать много.
Это понятно, но я подозреваю что автор знает что у него один поток и только его лочит на этом объекте.
D>Также, по крайней мере в теории, есть случаи, когда поток может проснуться "сам по себе".
Подробности этих случаев известны?
D>В приведённом мной коде наш поток точно проснётся и только тогда, когда хотим мы.
Ну, да. Но для одного потока и одного процессора команд, вроде как и исходный код в этом плане ничего. Или я чего-то не вижу?
Но в принципе идею понял. Если вдруг нужна будет многопоточная обработка, то много чего сразу перестанет работать.
Здравствуйте, Blazkowicz, Вы писали:
B>Это понятно, но я подозреваю что автор знает что у него один поток и только его лочит на этом объекте.
Лучше сразу выработать автоматизм в таких случаях. Появится второй поток и может много времени уйти ни на что. Тем более, что кроме "пользовательских" есть ведь ещё и другие потоки, мало ли, может кто из них вызовет notify на этом объекте.
D>>Также, по крайней мере в теории, есть случаи, когда поток может проснуться "сам по себе". B>Подробности этих случаев известны?
Не помню где, но читал каким образом может поток проснуться. Одни из вариантов было именно "сам по себе", мол редко, но случается. Найти не могу, может даже где-то здесь на РСДН инфа проскакивала. Если найду — ссылку кину.
B>Но в принципе идею понял. Если вдруг нужна будет многопоточная обработка, то много чего сразу перестанет работать.
Именно, лучше сразу сделать так как надо, это собственно в учебниках описывается. Тем более, надо то добавить одно поле и цикл, не такая уж большая плата за отсутствие потенциальных ошибок такого рода.
Кстати, вот сделали wait() на объекте. Потом этот объект где-то обратили в null, а потом разбудить забыли, что будет? Объект не будет уничтожен, пока на нём спит поток?
B>Прокомментируйте кто-нибудь, плз. А то не силён в много поточности.
Добавлю еще то, что такой код -- обычно реакция на факт того, что wait() и notify() бросают (по какой-то непонятной причине!) IllegalMonitorStateException, если они не находятся в synchronized блоке. Brute force решение -- это как раз обернуть вызовы этих методов в synchronized блок, что б JVM успокоилась. На самом деле, в synchronized блоке, кроме этих вызовов, должен быть еще и код, который обращается к объектам, к которым обращается код и из других потоков. В противном случае, мы рискуем получить общие объекты в неконсистентном состоянии из-за несинхронизированного доступа.
В приведенном случае
synchronized (this) { // этот this == commandProcessor из верхнего куска кода.
wait();
}
while (inputQueue.size() > 0) { // {1}
Command c = inputQueue.remove(0); // {2}
handleCommand(c);
Thread.yield();
}
несинхронизирован доступ к inputQueue. Несмотря на то, что в точке {1} проверяется размер коллекции, мы уже не можем с уверенностью вызывать в точке {2} remove(0) потому, что какой-нибудь другой поток мог эту коллекцию изменить. И то, что у этой коллекции методы сами синхронизированы (Collections.synchronized...) никак не спасает. Мы, конечно, можем посчитать, что вызов remove(0) совершенно безопасен поскольку другие потоки не удаляют элементы, а лишь добавляют их -- но это предположение базируется на логике кода, который физически удален от данного, а значит, это предположение легко может стать неверным в процессе эволюции программы.
Далее... wait() всегда должен быть в цикле, даже не столько из-за spurious wakeups, сколько из-за читабельности.
Глядя на
synchronized(this) {
wait();
// . . .
}
невозможно сказать какое событие мы в данном месте ждем без анализа остального кода. А глядя на такой
Здравствуйте, Blazkowicz, Вы писали:
B>Я не совем точно выразился. Наверное более подходящее определение "бесполезный цикл". То есть тот цикл который выполняется во время простоя. Если у тебя система в режиме ожидания ничего не делает, то соответственно никакой код выполнятся не должен. А когда система крутит циклы в своё удовольствие даже во время ожидания данных, тогда и загрузка процессора соответствующая.
Проблемный цикл найден! Собственно — вот он:
while (socketListenerThread == Thread.currentThread()) {
int keyNumber = selector.select();
if (keyNumber > 0) {
for (Iterator<SelectionKey> i = selector.selectedKeys().iterator();
socketListenerThread == Thread.currentThread() && i.hasNext();) {
SelectionKey key = i.next();
i.remove();
if (key.isValid()) {
if (key.isConnectable()) {
socketChannel.register(selector, SelectionKey.OP_READ | SelectionKey.OP_WRITE);
socketChannel.finishConnect();
} else if (key.isReadable()) {
clientLogger.debug("--> Readable key");
readPacket();
} else if (key.isWritable()) {
clientLogger.debug("--> Writable key");
writePackets();
}
}
}
}
}
От сервера всегда приходит один ключ с типом Writable, в результате чего этот цикл крутится впустую. Попытался динамически менять подписку на ключи — ключи начали теряться и происходил затык. Ещё один поток на отсылку не целесообразно вводить, ИМХО.
Подскажите, в какую сторону теперь копать для решения проблемы.
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, Blazkowicz, Вы писали:
BC>От сервера всегда приходит один ключ с типом Writable, в результате чего этот цикл крутится впустую. Попытался динамически менять подписку на ключи — ключи начали теряться и происходил затык. Ещё один поток на отсылку не целесообразно вводить, ИМХО. BC>Подскажите, в какую сторону теперь копать для решения проблемы.
Похоже на то, что использование NIO в данном случае не совсем оправдано, так как у тебя есть одно долго-живущее соединение, которое всегда готово к чтению/записи данных а вот сами то данные послупают относительно редко. То естьвесьтвой механизм работает в холостую.
Возможно стоит откатить программу на использование обычного блокируемого IO с двумя потоками — один на чтение второй на запись — надкладные расходы небольшие за асинхронность.
Как вариант, если уж так принципиально NIO, попробуй поиграться с регистрированием socketChannel в селекторе. То есть при пустой исходящей очереди ты подписываешься у селектора на OP_READ. При появлении элементов в очереди — устанавливаешь у SelectionKey interestOps на OP_READ | OP_WRITE (вероятно придется сделать wakeup селектору). Когда очередь становится пустой — вяртаешь OP_READ онли.
Здравствуйте, Donz, Вы писали:
D>>>Также, по крайней мере в теории, есть случаи, когда поток может проснуться "сам по себе". B>>Подробности этих случаев известны? D>Не помню где, но читал каким образом может поток проснуться. Одни из вариантов было именно "сам по себе", мол редко, но случается. Найти не могу, может даже где-то здесь на РСДН инфа проскакивала. Если найду — ссылку кину.
Здравствуйте, Donz, Вы писали:
D>>>>Также, по крайней мере в теории, есть случаи, когда поток может проснуться "сам по себе". B>>>Подробности этих случаев известны? D>>Не помню где, но читал каким образом может поток проснуться. Одни из вариантов было именно "сам по себе", мол редко, но случается. Найти не могу, может даже где-то здесь на РСДН инфа проскакивала. Если найду — ссылку кину.
D>Skipy с juga.ru нашёл корни, скорее всего в моём источнике упоминался именно этот случай: D>http://gcc.gnu.org/ml/java-prs/1999-q3/msg00072.html D>Может и ещё что-нибудь в этом духе встречается.
Решил продолжить тему, а как быть если у меня крутится RTP протокольчик где постоянно приходят пакеты с данными и остановка потока приравнивает к потере данных, если кто сталкивался с этим с удовольствием выслушаю??? С уважением Гришков И.О.
Здравствуйте, 245_Monah, Вы писали:
_M>Решил продолжить тему, а как быть если у меня крутится RTP протокольчик где постоянно приходят пакеты с данными и остановка потока приравнивает к потере данных, если кто сталкивался с этим с удовольствием выслушаю??? С уважением Гришков И.О.
Объясни куда это данные теряются? А то не очень понятно. Как по мне это равносильно тому что данные так же теряются если не вычитывать их не достаточно быстро?
Здравствуйте, Blazkowicz, Вы писали:
B>Объясни куда это данные теряются? А то не очень понятно. Как по мне это равносильно тому что данные так же теряются если не вычитывать их не достаточно быстро?
Вобщем принцип следующий, значить есть у меня кодер G729A енто вот это обращение "g729a.encode(g729a.handle, buffer, 0, buffer1, 0)", значить боролся я боролся что бы сбить нагрузку на проц и че та нифига неполучилось, кроме этого больше потоков не запущенно, этот запускается один раз, могу привести код самого Кодера G729A, еще прикол, значит пытаюсь весь код вставить в одну линейку в кодере что бы избежать многочисленных обращений к методам других классов, вобщем сократить количество переходов, но если я пытаюсь вставить метод конкретно в тело, то нагрузка увеличивается вдвое, пробывал отладочные печати, пустых цыклов ненашел, в чем бок для меня осталось загадкой С уважением Гришков И.О.
Здравствуйте, 245_Monah, Вы писали:
_M>привожу пример:
Ты жу не обижайся, но код форамтировать надо чтобы хоть кто-то удосужился прочитать. Так уж и быть подправлю твой пост.
_M>Вобщем принцип следующий, значить есть у меня кодер G729A енто вот это обращение "g729a.encode(g729a.handle, buffer, 0, buffer1, 0)", значить боролся я боролся что бы сбить нагрузку на проц и че та нифига неполучилось, кроме этого больше потоков не запущенно, этот запускается один раз, могу привести код самого Кодера G729A, еще прикол, значит пытаюсь весь код вставить в одну линейку в кодере что бы избежать многочисленных обращений к методам других классов, вобщем сократить количество переходов, но если я пытаюсь вставить метод конкретно в тело, то нагрузка увеличивается вдвое, пробывал отладочные печати, пустых цыклов ненашел, в чем бок для меня осталось загадкой _M> С уважением Гришков И.О.
А профайлер пробовал? Ты легко найдешь кто дает бОльшую нагрузку? inputAudioStream.read(buffer);
Может имеет смысл поигратся с размером буфера? Если к примеру inputAudioStream.read(buffer); вычитывает не очень много данных, то цикл выполняется очень часто. Если найти способ увеличть время выполнение цикла, пока буфер определенного размера не будет заполнен, то и цикл не будет выполнять а поток будет просто ждать пока прийдет достаточно данных. inputAudioStream хотя бы обернут в BufferedInputStream?
Здравствуйте, Blazkowicz, Вы писали:
B>Ты жу не обижайся, но код форамтировать надо чтобы хоть кто-то удосужился прочитать. Так уж и быть подправлю твой пост.
B>А профайлер пробовал? Ты легко найдешь кто дает бОльшую нагрузку? inputAudioStream.read(buffer); B>Может имеет смысл поигратся с размером буфера? Если к примеру inputAudioStream.read(buffer); вычитывает не очень много данных, то цикл выполняется очень часто. Если найти способ увеличть время выполнение цикла, пока буфер определенного размера не будет заполнен, то и цикл не будет выполнять а поток будет просто ждать пока прийдет достаточно данных. inputAudioStream хотя бы обернут в BufferedInputStream?
Неа, необернут, попробую этот вариант, просто уже крышу рвет от этого Кодера, просто я не думаю что следующий кусок кода "g729.encode(buffer, 0, buffer1, 0)" выполняется шустро, привожу пример пример одного из его методов "Квантование линейного спектра или Quantazing LSP":
А за форматирование прошу прощение, был напуган, с буфером попробую, но блин боюсь мало успеха будет, просто реально народ, уже бошка невыдерживает четвертый месяц немогу сбить нагрузку на проц и именно с Кодером, Декодер все чики пуки, а вот кодер какая то жопа, уже начал линейную структуру кода создавать, что бы Java меньше с переходами парилась
Здравствуйте, 245_Monah, Вы писали:
_M>Неа, необернут, попробую этот вариант, просто уже крышу рвет от этого Кодера, просто я не думаю что следующий кусок кода "g729.encode(buffer, 0, buffer1, 0)" выполняется шустро, привожу пример пример одного из его методов "Квантование линейного спектра или Quantazing LSP":
Все равно не понятно какого размера данные приезжают в буфер и как часто выполняется тело цикла.
_M>А за форматирование прошу прощение, был напуган, с буфером попробую, но блин боюсь мало успеха будет, просто реально народ, уже бошка невыдерживает четвертый месяц немогу сбить нагрузку на проц и именно с Кодером, Декодер все чики пуки, а вот кодер какая то жопа, уже начал линейную структуру кода создавать, что бы Java меньше с переходами парилась
Здравствуйте, Blazkowicz, Вы писали:
B>Все равно не понятно какого размера данные приезжают в буфер и как часто выполняется тело цикла.
B>Ключевое слово Profiler.
Размер буффера 160 байт, просто если я ремлю вызов кодера тогда бесконечный цикл, ну вернее пока приходят данные со звуковой карты, крутится без проблем и нагрузка на проц 04%, кароче понт ваабще, а тока подкидываю кодер, все машина умирает, а с профалером я все таки попробую покопать, наверное уже заффтра скажу результаты, спасибочки что отозвался
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, 245_Monah, Вы писали:
_M>>Неа, необернут, попробую этот вариант, просто уже крышу рвет от этого Кодера, просто я не думаю что следующий кусок кода "g729.encode(buffer, 0, buffer1, 0)" выполняется шустро, привожу пример пример одного из его методов "Квантование линейного спектра или Quantazing LSP":
B>Все равно не понятно какого размера данные приезжают в буфер и как часто выполняется тело цикла.
_M>>А за форматирование прошу прощение, был напуган, с буфером попробую, но блин боюсь мало успеха будет, просто реально народ, уже бошка невыдерживает четвертый месяц немогу сбить нагрузку на проц и именно с Кодером, Декодер все чики пуки, а вот кодер какая то жопа, уже начал линейную структуру кода создавать, что бы Java меньше с переходами парилась
B>Ключевое слово Profiler.
А подскажи пожалуйста, есть ли возможность в Профайлере, посмотреть конкретно что за цикл или что за опирации в цикле загружают процессор, потому что какие методы загружают я вижу но что конкретно в них загружет немогу понять???
С уважением Гришков И.О.
