Есть ли вариант использования для создания потоков без синхронизации и блокировки?

Question

Поскольку выполнение потоков происходит в пуле и не гарантируется постановка в очередь в каком-либо определенном порядке, тогда зачем вам создавать потоки без защиты синхронизации и блокировок? Чтобы защитить данные, связанные с состоянием объекта (что я понимаю как основную цель использования потоков), блокировка представляется единственным выбором. В конечном итоге вы будете в конечном итоге с условиями гонки и «поврежденными» данными, если вы не синхронизируете. Так что, если вы не заинтересованы в защите этих данных, тогда зачем вообще использовать потоки?

Answer 1

Если нет общих изменяемых данных, нет необходимости в синхронизации или блокировках.

Answer 2

Делегирование, просто в качестве одного примера. Рассмотрим веб-сервер, который получает запросы на подключение. Он может делегировать рабочему потоку конкретный запрос. Основной поток может передавать все данные, которые он хочет, рабочему потоку, если эти данные неизменны, и ему вообще не нужно беспокоиться о одновременном доступе к данным.

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

Answer 3

Синхронизация и блокировки защищают общее состояние от конфликтующих одновременных обновлений. Если нет общего состояния для защиты, вы можете запустить несколько потоков без блокировки и синхронизации. Это может иметь место в случае веб-сервера с несколькими независимыми рабочими потоками, обслуживающими входящие запросы. Другой способ избежать синхронизации и блокировки - заставить ваши потоки работать только в неизменном общем состоянии: если поток не может изменить какие-либо данные, над которыми работает другой поток, одновременный несинхронизированный доступ - это нормально.

Или вы можете использовать систему на основе Actor для обработки параллелизма. Актеры общаются только с помощью передачи сообщений, для них нет общего состояния, о котором они могли бы беспокоиться. Так что здесь вы можете иметь много потоков, выполняющих много актеров без блокировок. Эрланг использует этот подход , и есть библиотека Scala Actors , которая позволяет вам программировать этот способ на JVM. Кроме того, существуют библиотеки на основе акторов для Java .

Answer 4

В целях защиты данных, прикрепленных к состояние объекта ( что я понимаю быть основной целью использования темы ), блокировка Единственный выбор. ... Так что если вы не заинтересованы в защите эти данные, то зачем использовать потоки в все

Подсвеченный бит вашего вопроса неверен, и, поскольку он является основной причиной ваших "сомнений" о потоках, его необходимо устранить явно.

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

Потоки фактически не защищают состояние объекта каким-либо значимым образом. Защита, которую вы приписываете темам, обеспечивается:

• объявление членов с правом доступа,
• скрытие состояния за геттерами / сеттерами,
• правильное использование синхронизации,
• использование инфраструктуры безопасности Java и / или
• отправка запросов на другие серверы / сервисы.

Вы можете делать все это независимо от потоков.

Answer 5

java.util.concurrent.atomic предусматривает некоторые минимальные операции, которые могут быть выполнены без блокировки и в то же время поточно-ориентированным способом. Если вы можете полностью организовать параллелизм вокруг таких классов и операций, ваша производительность может быть значительно улучшена (поскольку вы избегаете всех накладных расходов, связанных с блокировкой). Конечно, необычно работать над такой упрощаемой проблемой (чаще всего потребуется некоторая блокировка), но, если и когда вы окажетесь в такой ситуации, тогда это именно то, что нужно если вы спрашиваете о! -)

Answer 6

Существуют другие виды защиты для общих данных. Возможно, у вас есть атомарные секции, мониторы, программная транзакционная память или структуры данных без блокировки. Все эти идеи поддерживают параллельное выполнение без явной блокировки. Вы можете Google любой из этих терминов и узнать что-то интересное. Если ваш основной интерес - Java, посмотрите работу Тима Харриса .

Answer 7

Потоки позволяют параллельно выполнять несколько параллельных единиц работы. Синхронизация просто защищает ресурсы шарда от небезопасного доступа, если он не нужен, вы его не используете.

Обработка в потоках задерживается при доступе к определенным ресурсам, таким как ввод-вывод, и может потребоваться, чтобы процессор обрабатывал другие единицы работы, в то время как другие задерживаются.

Как и в примере с другим ответом, прослушивание запросов на услуги вполне может быть единицей работы, которая не зависит от ответа на запрос как последний блок my из-за конфликта ресурсов - скажем, диск доступа или IO.