Свелось всё к классической задачке ^_^



Это сообщение отредактировал(а) Platon - 24.1.2008, 11:40

И получается не так уж и страшно:

Нет, вариант оказался неправильным, вот новый, но я даже не рискнул его запустить, просто не укладывается в мозгу как сделать правильно.
Опытные тредеры!!! Нужна консультация.



Добавлено через 6 минут и 47 секунд
Хм, нет, этот вариант конечно же завален.

Вот кажется валидный пример:

Усыплять поток - это всё равно что хальтовать процессор в ожидании немаскируемого прерывания :о))) Моветон :о) 
Да посади проц в фарева цикл на обработку задач :о)

Мыслить в контексте однозадачности - вот моветон.   
Вобщем, rtfm, как говорится.

Prol, от куда такие сведения? лупить в бесконечном цикле обработку задачи, которые поступают через неопределенные промежутки времени. Это убийство процессорного времени воистину!

Процессор должен работать, а человек - думать :о)

Не слипайте потоки, дайте им работу :о)
Если вы слипаете поток, значит он не нужен в вашей проге :о)
Зачем заводить поток, который вы же сами и останавливаете?

Вот классно сделано в транспьютерах: есть очередь процессоров, есть очередь задач,  свободный процессор отдаётся ожидающей задаче :о) Если процессорам нечего делать, значит все задачи выполнены :о)

Полная чушь!
1. Приостанавливать поток, и выполнять halt у процессора - это две большие разницы.
2. Если задача предполагает ожидание некого события, то поток должен заснуть, а не молотить никому не нужный цикл напрасно загружая процессор.

Добавлено через 46 секунд

Ты не понимаешь разницы между остановкой и приостановкой?

А какое отношение поток имеет к задаче? Это два разных объекта :о) Если задаче нужно чего-то ожидать, то причём тут поток? Поток передаётся другой задаче :о)

Тяжкое наследие DOS-а, сами распределяем память, сами организуем многозадачность  

Во первых попробуй реализовать такой механизм, и посмотрим что у тебя получится  
Во вторых, что ты будешь делать если нужные данные поступили и пора возвращать управление первой задаче, а вторая задача которая заняла поток, еще и не думает заверщаться, или хуже того блокирована на IO-операции?

Нет необходимости писать свое

Даг Ли создал отличную открытую библиотеку утилит параллельности, util.concurrent, которая включает объекты-мьютексы, семафоры, коллекции, такие как очереди и хэш-таблицы, хорошо работающие при параллельном доступе, и несколько реализаций рабочей очереди. Класс PooledExecutor из этого пакета - эффективная, широко использующаяся, правильная реализация пула потоков, основанного на рабочей очереди. Прежде чем пытаться писать собственное программное обеспечение, которое вполне может оказаться неправильным, вы можете рассмотреть использование некоторых утилит в util.concurrent. Библиотека util.concurrent включена в Java Development Kit 1.5.

Вот хороший учебник для овладения с практическими примерами.
http://gee.cs.oswego.edu/dl/classes/EDU/os...rent/intro.html




Это сообщение отредактировал(а) Prol - 27.1.2008, 16:49

В этом вопросе я уже не компетентен...

Добавлено через 9 минут и 33 секунды
хммм, в тамом случае, хотелось бы увидеть от Prol решения моей проблемы с помощью стандартного пакета Java, из этого я думаю, сможет получиться хорошая статья.

Это сообщение отредактировал(а) Platon - 27.1.2008, 17:25

Из java.util.concurrent в данном случае, я вижу применимость только для Lock/Condition. Каким образом ты предлагаешь использовать PooledExecutor для данной задачи?

Не морочьте голову   .  В java есть только потоки (threads). В приложении может быть запущено много потоков. Потокам выделяется память и периодически порция процессорного времени в зависимости от приоритета потока. Если для выполнения действий в потоке требуется дождаться некоторого события, то поток переводится в состояние ожидания и свою порцию процессорного времени использовать не будет.
Prol, java потоки - это воплощение вашей идеи с независимыми приложениями, использующими общую память. Можете гордиться   .  

Это сообщение отредактировал(а) COVD - 28.1.2008, 19:32