Что такое обсуждение потоков?

Ответ 1

По сути, конфликт потоков - это условие, когда один поток ожидает блокировки/объекта, который в настоящее время удерживается другим потоком. Поэтому этот ожидающий поток не может использовать этот объект, пока другой поток не разблокирует этот конкретный объект.

Ответ 2

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

Наиболее очевидным примером конкуренции является блокировка. Если поток A имеет блокировку и поток B хочет получить тот же самый замок, потоку B придется ждать, пока поток A не освободит блокировку.

Теперь это зависит от платформы, но поток может испытывать замедление, даже если ему не нужно ждать, пока другой поток освободит блокировку! Это связано с тем, что блокировка защищает какие-то данные, и сами данные часто будут обсуждаться.

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

Почему? Скажем, что каждый поток работает на собственном ядре на современном процессоре x86, а ядра не имеют кэш L2. Только одним потоком объект может оставаться в кэше L2 большую часть времени. Когда оба потока выполняются, каждый раз, когда один поток изменяет объект, другой поток будет обнаруживать, что данные не находятся в его кэше L2, потому что другой ЦП недействил линию кэша. Например, на Pentium D это приведет к тому, что код будет работать со скоростью FSB, что намного меньше скорости кэша L2.

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

Как ни странно, блокировки обычно сокращают конкуренцию. Зачем? Поскольку без блокировки два потока могут работать на одном и том же объекте или в коллекции и вызывать много конфликтов (например, есть свободные очереди). Замки будут иметь тенденцию деша расписывать конкурирующие потоки, позволяя вместо этого запускать непротиворечивые потоки. Если поток A содержит блокировку и поток B хочет эту же блокировку, реализация может вместо этого выполнить поток C. Если нить C не нуждается в этой блокировке, то в будущем соперничество между потоками A и B можно избежать некоторое время. (Конечно, предполагается, что существуют другие потоки, которые могут выполняться. Это не поможет, если единственный способ, который система в целом может сделать полезным, - это запустить потоки, которые конкурируют.)

Ответ 3

От здесь:

Конфликт возникает, когда поток ожидая ресурса, который не является легко доступны; он замедляет выполнение вашего кода, но может очистить с течением времени.

Тупик возникает, когда поток ожидая ресурса, что второй нить заблокирована, а вторая поток ждет ресурса, который первый поток заблокирован. Больше, чем два потока могут быть задействованы в тупиковый. Тупик никогда не решает сам. Это часто приводит к приложения или части, которая испытывая тупик, чтобы остановиться.

Ответ 4

У вас есть 2 потока. Thread A и Thread B, у вас также есть объект C.

A в настоящее время обращается к объекту C и поместил блокировку на этот объект. B должен получить доступ к объекту C, но не может сделать этого до тех пор, пока A не освободит блокировку объекта C.

Ответ 5

Я думаю, что на фоне вопроса должно быть какое-то разъяснение из OP - я могу придумать 2 ответа (хотя я уверен, что есть дополнения к этому списку):

• если вы имеете в виду общую "концепцию" обсуждения потоков и как она может присутствовать в приложении, я откладываю подробный ответ @DavidSchwartz выше.

• Существует также .NET CLR Locks and Threads: счетчик производительности Total # of Contentions. Как взято из описания PerfMon для этого счетчика, оно определяется как:

  Этот счетчик отображает общее количество раз, когда потоки в CLR пытались получить управляемую блокировку безуспешно. Управляемые блокировки могут быть приобретены разными способами; оператором "lock" в С# или вызовом System.Monitor.Enter или с помощью MethodImplOptions.Synchronized custom attribute.

... и я уверен, что другие для других ОС и рамок приложений.

Ответ 6

Другим словом может быть concurrency. Это просто идея двух или более потоков, пытающихся использовать один и тот же ресурс.

Ответ 7

Я считаю, что конкуренция между двумя и более потоками по общему ресурсу. Ресурсом может быть блокировка, счетчик и т.д. Конкурс означает "кто его первым". Чем больше потоков, тем больше споров. Более частый доступ к ресурсу вызывает больше разногласий.

Ответ 8

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

Ответ 9

Конфликт блокировок происходит, когда поток пытается получить блокировку для объект, который уже получен другим потоком *. Пока объект, поток заблокирован (другими словами, он находится в Состояние ожидания). В некоторых случаях это может привести к так называемому серийному которое отрицательно влияет на приложение.

из документация dotTrace

Ответ 10

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

Как и в примере, два случая дают смысл соперничества.