Какова цель метода Thread.SpinWait?

Ответ 1

нет. Его использовали в качестве замены для очень коротких вызовов сна.

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

Однако иногда вы ждете крошечного количества времени. В таких случаях вы обычно отказываетесь от своего оставшегося времени и дожидаетесь того, что все остальные потоки будут делать свое дело, прежде чем идти дальше... так что вы можете обманывать, а не ждать, вы сидите там постоянно, показывая, что "мы почти еще? путь. Если блокировка удерживается только на оставшуюся часть времени, это становится очень эффективным средством ожидания, что также очень эффективно, так как планировщик не должен участвовать в перестановке всех других потоков, чтобы использовать время, которое вы сдаете если вы обычно ждали.

Очевидно, что если вы вращаетесь каждый раз, когда хотите блокировку, вы не будете очень популярны, ваше приложение станет вялым и будет использовать 100% процессор, но в очень малых дозах, в нужное время, это делает приложение более отзывчивое.

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

Ответ 2

Цель состоит в том, чтобы сделать "дешевое" ожидание, если вы считаете, что состояние, которого вы ожидаете, сбудется очень скоро. Обычно, если вы чего-то ждали, вы позволяете потоку спать, а процессор/ОС переключит контекст на другой поток. Контекстные коммутаторы не особенно дешевы, поэтому, если у вас есть передовые знания о ситуации и считаю, что дешевле ждать, чем переключиться на контекст, вы будете ждать.

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

Ответ 3

В качестве дополнительной заметки Microsoft избавилась от механизма спинблока диспетчера потоков от Windows 7, поскольку он не очень хорошо масштабируется для многоядерных процессоров. Посмотрите это:

Ответ 4

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

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