2010-06-15 2 views
7

Многопоточность свойства языка (например, java) или свойства ОС?Многопоточность свойства языка (например, java) или свойства ОС?

+0

Почему вы спрашиваете? Простой ответ заключается в том, что он ... –

+0

Threading - это свойство платформы. В случае Java Java также является платформой (VM). – CurtainDog

+0

@codeka: Правильный ответ, однако, заключается в том, что это не так. Это аппаратное обеспечение, которое операционные системы и/или языки могут использовать, если они разработаны правильно. Однако без упомянутой аппаратной поддержки (даже если это просто прерывание по таймеру) вы не собираетесь получать многопоточность. –

ответ

5

Ни то, ни другое. Это свойство базового оборудования. ОС и языки помогают нам использовать средства, предоставляемые оборудованием.

Wiki может помочь: http://en.wikipedia.org/wiki/Multithreading

+6

Многопотоковая передача (и есть) существует без помощи аппаратного обеспечения (ну, как минимум, аппаратное обеспечение прерывает таймер) –

+0

Да. Но это зависит от оборудования. Если поддержка многопоточности не поддерживается, даже если мы используем API, предоставляемый языком, положительного результата не будет. Таким образом, по вопросу OP, многопоточность является «свойством» harware, и только поддержка обеспечивается ОС и Java (или аналогичными другими языками). – bdhar

+1

+1, но поддержка языка/библиотеки помогает. –

4

Многопоточность действительно полагается на аппаратные возможности, но для большинства платформ «тяжелую» осуществляется с помощью операционной системы. Это важно, особенно в современных многоядерных системах. ОС также обеспечивает возможности блокировки и мониторинга.

Сказав это, появились платформы, на которых много виртуальных машин, в том числе планирование и блокировка, реализованы на многих виртуальных машинах, а не в ОС. Они известны как Green Threads. Однако они имеют ограничения в многоядерных системах и уступают место естественным потокам ОС на самых императивных языках.

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

0

Чтобы добавить к вышеуказанным пунктам, когда мы говорим, сколько потоков может выполняться одновременно? Тогда это зависит от процессора, как двухъядерного и в настоящее время четырехъядерного ядра. Таким образом, каждый процессор имеет потенциал для одновременного запуска потока. Это аппаратно-зависимая вещь. Надеюсь, мое понимание правильное, и другие члены меня исправят, если я ошибаюсь.

+0

Зависит от того, что вы подразумеваете под «одновременным запуском». Нитки были вокруг перед многоядерными системами, и они по-прежнему чрезвычайно полезны. – CurtainDog

0

В конечном счете это свойство оборудования. У Java были возможности потоковой передачи с самого начала, но они были значительно более полезны с введением пакетов java.util.concurrent.

Настоящий mulltithreading полезен для современного оборудования, которое позволяет выполнять несколько потоков. На более раннем оборудовании особенно операции ввода-вывода могут быть понятны и управляемы при использовании отдельного потока, который может быть заблокирован в ожидании данных.

1

Модель программирования должна иметь согласованность и/или модель памяти. Например, у Java есть потоки и это memory model (обзор в Википедии). Это явно относится к семантике языка программирования, его спецификации.

Другие языки программирования могут иметь другие абстракции параллелизма (думать о clojure с агентами и т. Д.) Или другую модель памяти. Чем проще модель памяти, тем проще использовать язык. И наоборот, сложная модель памяти делает параллелизм довольно трудно сделать правильно (подумайте об определении volatile в Java). Поэтому некоторые люди утверждают, что языки программирования не должны иметь модели памяти.

Фактическая реализации от параллельности и/или модели памяти до реализатора языка. Вы можете использовать OS-процесс/нить, или VM может эмулировать потоки (так называемый green thread).Есть даже другой подход: сверхлегкие потоки, например Kilim.

Однако, чтобы реально использовать multicore, вы должны использовать потоки ОС (по одному на ядро), в противном случае нет аппаратного параллелизма. Но «логические» потоки, используемые программой, могут быть запланированы легким способом на потоках ОС N. Насколько мне известно, невозможно указать JVM, сколько потоков ОС использовать для планирования зеленых потоков. Если у кого-то есть указатель на это, это было бы интересно.

Подводя итог: Многопоточность является логической концепцией. Приложение может быть многопоточным, но работать на одном ядре. Многоядерный параллелизм - это аппаратная концепция. Чтобы использовать параллелизм mutlicore, виртуальная машина должна реализовывать потоки, чтобы использовать процесс ОС, который будет работать на разных ядрах.

EDIT

На самом деле Java резьб и модель памяти теперь описывается в специальной спецификации JSR-133 вместо главы 17 спецификации языка Java. Дополнительная информация о JSR-133 FAQ

Смежные вопросы